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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


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


Farrukh,

I know we've had this disagreement before.  I'm not
arguing with you from the registry engineering PoV -
I understand why the registry itself needs these UUID
keys internally.

It's the way they get used externally that frankly does
not meet the business use case of things like CCTS,
CPA, BPSS, CAM and more.

Your point about the 16 bytes reminded me of another
big issue -using these UUIDs you also need to avoid
embedding the URL for the registry too - making this
even more ugly (what if you need to relocate your registry
to a new server?).

Here's an example from Duanes code - I count a lot
more than 16 bytes here:

"urn:uuid:4a593056-3509-0766-2e7b-4e154030423f"

By comparison the UID system is available to
prevent having to do all this syntax mucky-muck.
Using the character code prefix - the Registry is
referenced via an ALIAS and therefore the
physical address location can be easily and
quickly changed by assoicating the alias to the
registry address - and the UID values themselves
can be assigned simply and easily with a code
that makes sense to the
business functional users, and can be versioned
and sub-versioned directly.

Example UID:   USPS020015

United States Postal Service BIE - in the 20000
series - all of which relate to Mailing Address
structure elements, and so on.

And then UID:  USPS020015:01:03

is version 01, sub-version 03 - of that same BIE
structure - where say the country codes have been
updated for the new members of the EU countries.

This is why we put the EXTERNAL ID functionality
in the Registry RIM - and that is why we should be
recommending people use it for CCTS and other
content referencing needs.   It provides domain-centric
labelling of content and that is a very good thing that
we should be advertizing as an excellent feature.

The UUID takes us backwards - that's how we
ended up with EDI in the firstplace - completely
dictated by machine level technology devices and
mechanisms - instead of business use
case needs.  The whole point of CCTS is to move
beyond machine level stuff to a higher business
neutral system.  Using UUIDs is like thorns on a rose
IMHO here.

Thanks, DW

----- Original Message ----- 
From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
To: "David RR Webber" <david@drrw.info>
Cc: "Duane Nickull" <dnickull@adobe.com>; "UN/CEFACT Core Component WG"
<uncefact-tmg-ccwg@listman.disa.org>; <regrep@lists.oasis-open.org>
Sent: Friday, April 09, 2004 9:13 AM
Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's


> David RR Webber wrote:
>
> >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 respectfully disagree. The UUID based URN (urn:uuid:....) should be
> used to
> uniquely reference an object internally or externally. I agree that for
> human
> consumption you may want some ExternalIdentifier such as a human
> friendly URN.
> But strictly for reference purposes (internal or external to registry) I
> still
> suggest using UUID based URNs.
>
> >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....
> >
> >
> Oops, I think you meant to say a "16 byte boat anchor" not a "128 byte
> boat anchor".
> Which is definitely less than "30 bytes of information".
>
> To be clear... A UUID is 16 bytes not 128 bytes.
>
> -- 
> Regards,
> Farrukh
>
>
>
> 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.
>
>



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