UPD Mail Archive: UPD> key/keyref

UPD> key/keyref

From: Norbert Schade (norbertschade@comcast.net)
Date: Mon Jan 26 2004 - 15:57:32 EST

  • Next message: Norbert Schade: "UPD> UPDF Version"

    With UPDF we focus not only on providing a proper structure for a device description.
    We also try to guide the developer, who eventually will create instances based on the schemas.
    One way to do it is to work with predefined attribute values. We do that in the definition of the ClassifyingID.
    Another way is to use patterns. We do that in various places, mainly in the definition of the ClassifyingID.

    We have been working on yet another method to prevent developers from entering wrong values in elements and attributes. This implicates the use of identifiers and cross references.
    1. attribute type ID.
    We have defined almost all attributes with name ID as type xsd:ID (checking the remaining ones). This ensures uniqueness of all identifiers across the whole instance.
    2. attribute type IDREF.
    Some attributes are declared IDREF, like NonDominantRepresentative (checking further implementation).
    This allows - depending on the XML application - suggested lists a developer can select a value from.
    3. keys
    Lately we have defined keys. e.g. we have defined keys on all features.
    4. keyrefs
    On top of keys you can define keyrefs. e.g. we have defined keyrefs on the NonDominantRepresentative attributes.
    No the XML application has numerous chances to validate correct entries and even show proper messages for bad ones.

    We consider this type of cross references and validation superior functionality to make the whole system more user friendly.

    Files are on the web.

    Norbert Schade

    Norbert Schade
    69 Prescott Drive
    North Chelmsford
    MA 01863
    phone: 1-978-251-1017
    email: norbertschade@comcast.net

    This archive was generated by hypermail 2b29 : Mon Jan 26 2004 - 16:01:26 EST