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