[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: LONG: RE: [regrep] Issue with UUID's for Core Components and BIE's
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:email@example.com] Sent: Friday, April 09, 2004 11:29 AM To: Farrukh Najmi Cc: Duane Nickull; UN/CEFACT Core Component WG; firstname.lastname@example.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" <email@example.com> Cc: "Duane Nickull" <firstname.lastname@example.org>; "UN/CEFACT Core Component WG" <email@example.com>; <firstname.lastname@example.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.