[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RE: [regrep] Issue with UUID's for Core Components and BIE's
Matt, Once again I have to reinforce my point - you are talking about middleware programming techniques - and I am not trying to change those - but we simply cannot have a situation where the middleware is dictating the business needs and user mechanisms. Sure it would be easier if all banking statements were written in reverse polish notation - I just don't think many bankers would buy that software solution off you however. The bottom line is - people need simple mechanisms - and the proven fact is they use reference codes to identify content of all kinds. Computers should serve people - not the other way around. Take for instance your statement: > 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. So a prefix is hokey - but embedding a bunch of techno-goup is much better!?! Sorry - this dog does not hunt in my book. The real answer is to separate the two mechanisms - not mush them together. The prefix mechanism I referenced in the UID is absolutely NOT there to provide assess path information - its solely a visual cue to the human. Here's an example of using a referencing system that does not rely on mushing information into a URN - and supports *any* access system - not just DNS based - so you can use SQL stored procedures, OS file system, RPCs, ebMS, whatever - to implement your content accessing - so you can have a reference to something like "0021-BeingTypeIdentfier.xml" as in the example below - (personally I would prefer "CCTS000021" here - but the intent is to show the flexiblity and means to accommodate "any* deployment system, and actually there's nothing to stop you using more than one labelling and that is also very important - as people will need UDEF, OAGi, and more labels for potentially the same term - and then associate them): <ContentReference> <Addressing> <registry name="CCTS" access="registry.my-house.ca:8080" method="http-binding" description="Test CCTS Dictionary Registry access"/> </Addressing> <item type="noun" name="//BeingTypeIdentifier" UIDReference="0021-BeingTypeIdentfier.xml" taxonomy="XMLpath" registry="CCTS" ccts:modeltype="BIE" /> </ContentReference> Final point - the human friendly code system can be equated under-the-hood to the UUID and then the UUID used for all the machine internal linkages - but it is a mistake to expose the UUID outside of the registry at the human interface level. It's confusing, its unnecessary and it is a formidable turn-off for people who would otherwise want to adopt ebXML Registry for their work. I can give you direct quotes from people looking at screens from YDS and XMLG registry implementations - WRT UUIDs being displayed on them - but this is a family channel rated 'G' only! Cheers, DW. ----- Original Message ----- From: "Matthew MacKenzie" <mattm@adobe.com> To: "'David RR Webber'" <david@drrw.info>; "'Farrukh Najmi'" <Farrukh.Najmi@Sun.COM> Cc: "'Duane Nickull'" <dnickull@adobe.com>; "'UN/CEFACT Core Component WG'" <uncefact-tmg-ccwg@listman.disa.org>; <regrep@lists.oasis-open.org> Sent: Saturday, April 10, 2004 10:15 AM 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: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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]