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