[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] Bill&Eve's proposal on local/global elements
I hope that you all decided this in Menlo Park this last week, but I just want to go on record as saying I like this approach. Mike "Eve L. Maler" wrote: > 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 > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC