[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Bill&Eve's proposal on local/global elements
The following was whipped up by Bill and Eve after we recessed for the day. We hope it's coherent, and will lead to productive discussion tomorrow. * * * Parties need identifiers. Addresses need identifiers. In both cases, the structural profile of the identifier is identical, and yet the "meaning" is not entirely identical. They do share a significant overlap: the "intrinsic meaning" is identical, but the meaning in the role they play will differ (a party identifier or an address identifier). You need to know the role-enhanced meaning in order to have the full picture. It is precisely the role-enhanced meanings that ISO 11179 dictionary entries convey. (For example, Party.Identifier is the dictionary entry name in the CC Catalogue that has UID 000016 and CCT Identifier.Type. Many other entries have the same type.) A strong analogy can be made to the situation with defining types and elements in schemas. The CCT Identifier.Type can be thought of as an XSD type that is reusable for defining many different elements. Those elements will be structurally identical, but the XML hierarchy in which they appear determines the role they are playing. Everything you need to know about an element instance in a document can be found by looking at two facts about it: - The description of its type (its intrinsic meaning; note that ISO 11179 is mute on this subject) - The dictionary entry for that element (its role-enhanced meaning), which indicates its object class, property term, and representation term (this is the subject of ISO 11179) Whether we declare elements globally or locally, it is the case that we need both these pieces of information. The contention seems to be over whether elements need a globally unique name in order to be unambiguously identified in the data dictionary. Here is how we think it could be done using local elements. The schema would look like this (very simplified): <xsd:complexType name="IdentifierType"> ... </xsd:complexType> <xsd:complexType name="AddressType"> <xsd:sequence> <xsd:element name="Identifier" type="IdentifierType" /> ... </xsd:sequence> </xsd:complexType> <xsd:complexType name="PartyType"> <xsd:sequence> <xsd:element name="Identifier" type="IdentifierType" /> <xsd:element name="Address" type="AddressType" /> ... </xsd:sequence> </xsd:complexType> We defined an identifier BIE (IdentifierType). Then we defined an address BIE that has as one of its properties an identifier. Then we defined a party BIE that has as one of its properties an identifier, and as another of its properties, an address. The instance would look like this: ... <Party> <Identifier>...</Identifier> <Address> <Identifier>...</Identifier> </Address> </Party> ... Assuming a convention to declare elements locally as we've just illustrated, can we connect each of the elements in this instance unambiguously to a dictionary entry? Yes. The unambiguous dictionary entry name is the type name followed by the element name, separated (if you wish) by a dot. For example: Party.Identifier Address.Identifier The reason we know this is unambiguous is because each of the type and the element names are unique in their respective scopes. There have been a number of arguments advanced for using locally declared elements, primarily the argument for encapsulation (though there are others), and there have been no arguments advanced specifically for globally declared elements beyond the concern about producing dictionary entry names for local elements. The foregoing example demonstrates that dictionary entry names can be produced for local elements. -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC