Proposed UUID Equivalence Mapping Methodology

["Petit, John" <jpetit@kpmg.com>]

UUID mapping allows a schema (DTD, SOX, EDI, etc.) author to equate any
number of their schema elements to another registered set of schema elements
via UUIDs. UUID mapping has been discussed within CC for some time, and
alluded to in several documents, but it has yet to be fully addressed by the
hard working, but over-burdened, CC group. Without overstepping my bounds,
but in the interest of time as Vienna is quickly approaching, I propose that
three, simple XML documents be included in the Registry. These three XML
documents will allow basic UUID mapping between ebXML user documents and
classification systems (ISO, ANSI, DUNS, etc.):
*	UUIDEquivalence.xml
*	UUIDAssociatedMaps.xml
*	UUIDTransformationRules.xml 
For those who would like some background on how UUID mapping will be
utilized with in the ebXML framework, see the following section "Role of
UUID Mapping."

UUIDEquivalence.xml: This document captures the mapping information. As
ebXML will be interfacing with EDI, DTDs, Schemas, SOX, etc, such simple
equations have a wide use. It allows any group of UUIDs to be equated, even
if they do not belong to separate schemas. The "DestinationRegistry"
attribute is optional, and would only be used if referring to UUIDs outside
the local Registry. We are not defining how the translation will be made,
only providing the basic data for that transformation. It is up to the agent
software to determine how to translate the documents.  While these docs can
be created by hand or from any number of tools, I imagine that graphical
editors will eventually surface to aid in the creation of UUID maps. Also
optional is the use of a TransformationRule (described below).

<Equivalences DocUUID=" [UUID] ">
	<Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
" DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
	<Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
" DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
	<Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
" DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
	<Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
" DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
</Equivalences>

UUIDAssociatedMaps.xml: For any given UUID (identified by the "ForWhichUUID"
attribute), there may be any number of equivalencies made. For example, an
element within a product catalog may be equated to several different product
catalog schemas. In seeking to construct a reference chain between two
schemas, an agent would have to check all the equivalence maps for a given
element.  For more information on reference chains, see section below.

<AssociationCollection>
	<AssociatedMaps ForWhichUUID=" [UUID]  ">
		<AssociatedMap UUID=" [UUID]  "/>
		<AssociatedMap UUID=" [UUID]  "/>
		<AssociatedMap UUID=" [UUID]  "/>
	</AssociatedMaps>
</AssociationCollection>

UUIDTransformationRules.xml: Optional transformation rules can be used in
situations in which there are cardinality discrepancies, data format
changes, and value splitting/joining. The rule format is unrestricted
(JavaScript, XSLT, Java, etc.). As there will be many situations in which
the transformation is the same algorithm or rule, then being able to select
rules separately aids in code reuse. A set of format codes should be defined
so that agents will be able to recognize the various formats. Again, it is
up the agent software to be able to process the transformation rules.

<TransformationRules>
	<TransformationRule RuleUUID=" [UUID] " >
		<LocalSourceToDestination format="[format]" [Optional
external doc reference]> [rule]	</LocalSourceToDestination>
		<DestinationToLocalSource format="[format]" [Optional
external doc reference]> [rule]	</DestinationToLocalSource>
	</TransformationRule>
	<TransformationRule RuleUUID=" [UUID] " >
		<LocalSourceToDestination format="[format]" [Optional
external doc reference]> [rule]	</LocalSourceToDestination>
		<DestinationToLocalSource format="[format]" [Optional
external doc reference]> [rule]	</DestinationToLocalSource>
	</TransformationRule>
</TransformationRules>


Role of UUID Mapping: The ability to map one ebXML user document to another
based on UUIDs will solve many problems facing ebXML. UUID mapping will aid
in joining heterogeneous document types within a single document category
(ex.: search all real estate listings even though they have different tag
structures). Foreign languages, even structuring simple elements such as
partner info can and probably will be tagged and structured differently.
These maps capture the conceptual leap that a human can make but that an
agent cannot make in equating individual elements. ebXML has been designed
in a very loose fashion so that industries can define their own data
structures and use a variety of technologies to do so. While this looseness
is broadly appealing, it presents some serious concerns in terms of basic
data interoperability. This system of UUID mapping is also loose, as there
is no requirement that documents be mapped at all. However, it will allow
ebXML to grow organically. Like microfilaments in a root system, eventually
a contiguous net of connections will be formed.

Such maps could also bridge various classification systems such as ISO,
ANSI, etc.

getHierarchy() function: This would return the nesting structure of a given
element or UUID.

UUID Reference Chains: Lets say for example that two companies have
registered ebXML documents that they want to translate between in order to
do business (Purchase Order forms, etc.). By checking the UUID Association
Maps, an automated search agent can begin to search through all the
registries that these documents are mapped to until it finds a common link
between the two documents. Essentially this is long process of "if document
A = B and B = C and C = D and D = E, then A = E." This is a UUID reference
chain. As ebXML grows, and more and more documents are mapped, this sort of
agent based translation will become more and more robust.


Cheers, John Petit

*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************