Re: [ubl-ndrsc] Bill&Eve's proposal on local/global elements

[Mike Rawlins <mike@rawlinsecconsulting.com>]

One thing I do need to note, however, in case it did not come up in discussion:

There is *not* a one-to-one correspondence between CCTs and Representation Terms
in the latest CC technical spec.   For example, the representation terms Percent,
Rate, and Value all "link" to the CCT Numeric.Type.  Date Time.Type and Text.Type
also have such many-to-one links.  At first glance I'm not quite sure of the
impact that this has on the proposed scheme, but I have a feeling that it needs
to be considered.   If the scheme is in any way dependent on a one-to-one link
between types (XML schema type declarations and CCTs) and representation terms,
it is going to have problems.

BTW - I think this many-to-one relationship between representation terms and CCTs
is, at best, an awkward feature of the current CC spec and will so state during
the public comment period.

"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