Re: [regrep] Issue with UUID's for Core Components and BIE's

["David RR Webber" <david@drrw.info>]

Duane,

This must be the hundredth time that we've gone over this.

The UUID is intended for internal use within the registry
only.

It is poor practice to expose it outside of the internal workings
of the registry - ESPECIALLY as it is impossible to version UUID
values - or corrolate them in sequence.

Please, please, please, please STOP trying to do it this way
with UUIDs - you are just creating a maintenance nightmare
long term.   And then the OTHER HUGE mess we discovered
at XMLGlobal - which was never resolved - is what happens
if you want to export content out of one registry - and import
it into another - then the new registry assigns new UUIDs to
everything - therefore breaking any cross referencing that
was in the original - and so on and so forth.

NO - UDEF id is not a good substitute either - because they
cannot be machine generated today.

Within ebXML we have already defined the UID mechanism - and
this is documented in many places - including the CCTS spec' -
that is a prefix of an alpha character alias, followed by a 6 digit
number, and then an optional version suffix.  These UID values
can and should be stored in the Registry EXTERNAL ID field -
of the RIM - and again this is documented in the registry
specifications as being for this purpose - and the registry
supports retrieval on EXTERNAL ID key values.

By using these neutral UID values - you get out from under all the
problems the UUID brings.  Also notice that UID can
accept existing dictionary element references - such as
EDIFACT element IDs, OAGi BOD element #, other industry
domain reference ID as needed.  This flexibility is key.

Finally UID values can be assigned to BIEs, or any other
component of ebXML.  For instance the BPSS specification
is successfully using UID values to ID components within
the BPSS itself, UID values can ID CPA agreements, and so on.

I hope this is the last and final time we have to have this discussion
around erroneous use of UUID values as external linkage identifiers
to registry content - they are for INTERNAL use only - and should
be used for such programmatic pointer uses only within the API
to registry.   I understand the tempatation to make your Java code
easier to write by burying all these UUIDs into the access method
to the registry - as a quick kludge - but you have to remember the
central tenet of computer software - its supposed to make work
easier for human operators - not harder!   Not to mention the
ludicrous overhead associated with a 128 byte boat anchor to
what is often less than 30 bytes of information....

Cheers, DW.

----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
To: "UN/CEFACT Core Component WG" <uncefact-tmg-ccwg@listman.disa.org>;
<regrep@lists.oasis-open.org>
Sent: Thursday, April 08, 2004 8:35 PM
Subject: [regrep] Issue with UUID's for Core Components and BIE's


> Apologize for the cross post in advance, but I feel both of these groups
> need to address this issue.
>
> The Core Components and Registry specs both mandate a unique identifier
> to be used in certain places.  IN the registry, it is for every single
> registry object.  Each Core Component also must have an identifier.
>
> In a recent project I did, I decided to use the registry UUID format for
> the Core Components.  That is the DCE 128 bit algorithm for generating
> UUID's.  We also demonstrated programmatic access to the registry to
> retrieve copies of Core Components, slurped them into a context assembly
> utility along with an XML declaration of the 8 context categories and
> values representing a specific set of contexts, and spat our several
> BIE's, which were aggregated onto an XML schema.  The good news is that
> all went well and the system works perfect.
>
> There were some questions however that do need further discussion IMO.
>
> 1. Should a BIE carry the same UUID as the Core Component it was derived
> from?
>
> 2. Either in addition to, or alternatively to #1, should a BIE carry
> its' own unique UUID?  If it is placed into a registry, the UUID will be
> assigned to it by the registry, but it also need to be serialized inline
> into the BIE to be used outside of the registry or in places where
> access to the Registry RIM instance data is not possible. (real world
> use cases exist for this).
>
> 3. If the BIE does have to have it's own UUID, possibly in addition to
> the COre COmponents UUID, should this UUID be in the 128 bit algorithm
> format OR should it use something akin to the UDEF format that can
> convey context variables?  This may be crucial to aid business mappers
> and integration software (rich client applications) to map the BIE to
> existing data sources.
>
> Thank you for any comments on this.  I have done it one way but would
> like to not reply with what I have done until I hear ideas from others
> since I am not happy with my solution.
>
> Duane
>
> -- 
> Senior Standards Strategist
> Adobe Systems, Inc.
> http://www.adobe.com
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>