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

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

+1 on all of Matts points.

Matthew MacKenzie wrote:

>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.
>
>
>
>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.
>
>  
>


-- 
Regards,
Farrukh