OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[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.


"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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC