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

[Matthew MacKenzie <mattm@adobe.com>]

A UUID is meant to be unique in time and space.  Frankly, they are
universally adopted.  With ebRS supporting a predictable URL format via its
HTTP binding, we really should be looking toward defining mechanisms for
making registry location information available such as in DNS.  A ID
mechanism that embeds some prefix in it is a hokey solution, and its error
prone unless each organization manages their namespace carefully.

One idea is to embed some more info in the urn, and use a DNS driven
approach for resolving an extended urn string to a registry object download
URL.

We take a root domain name of 'r.ebxml.org', this is our address space.  A
committee at OASIS is in charge of maintaining this namespace.

Organization 'A'would like to register its registry, so they submit a
request to the OASIS team looking after this.  The request might look like:

"A Corp. would like to register two registry instances in the global
"directory".  Instance One is called "osirus" and it is at
http://osirus.corp.com/http-binding.  The second instance is called
"ogmios", and it is located at http://ogmios.corp.com/http-binding.";

Upon receiving this request, the OASIS team would register a domain name for
the organization in DNS:

a.r.ebxml.org.  In the TXT field for that domain, would be a token like:

ORG:A Corp

Two more subdomains would also be created:

Osirus.a.r.ebxml.org
  --> TXT field: http://osirus.corp.com/http-binding

Ogmios.a.r.ebxml.org
  --> TXT field: http://osirus.corp.com/http-binding

Federations could be accommodated by creating further sub-domains for
"virtual" registries, e.g. ogmios.clusterA.a.r.ebxml.org.

Now...The UUID: urn:uuid:osirus:a:UUID-7888-HHHH-UUUU

Using standard DNS resolver libraries + that UUID, we can find out the HTTP
binding location.  Since we are using DNS infrastructure, it is likely that
no special configuration will be needed, and the system is proven to be
ultra scalable. 

If I get a couple hours, I will demonstrate this technique.  

I don't think we need domain specific ID references.  What we need is unique
identifiers that can always be resolved to their registry content or entries
by authorized users from anywhere.  Nobody cares that the UUID is difficult
to type and remember, because these things are used by software.

-matt



-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Friday, April 09, 2004 11:29 AM
To: Farrukh Najmi
Cc: Duane Nickull; UN/CEFACT Core Component WG; regrep@lists.oasis-open.org
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.
>
>


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.