Subject: Re: GUID: Registry Information Model v0.41
David, Welcome back and thanks for your comments. See my comments inline: David RR Webber wrote: > Message text written by Farrukh Najmi > >It is proposed that this version be submitted to Quality Review modulo > changes based on feedback. > > I look forward to your comments and suggestions. > <<<<<<<<<<<<<<<<<<<<<<<<<< > > Farrukh, > > Some comments: > > 342 : Registry GUID for this object. Globally > unique. It is recommended to use DCE 128 bit GUID. > > http://msdn.microsoft.com/library/books/inole/S10E8.HTM > > >>>> This approach while just fine for generating internal > reference codes, is not OK for the business need > we have. I would assert primarily since that these > GUID's are NOT just machine goup - but also > items that at some point humans may need to > verify and handle. While this may be used in tandem > with DCE 128 - we still need EDI style labelling ie. > > GCI08301 and AIG00234 and so forth. > > These mechanisms are simple - but also easy for > humans to understand. 3 byte prefix - 5 digit reference, > where the 3 byte prefix refers to the owner organization. I humbly disagree. The fundamental premise I have is that GUIDs are purely for machine consumption and not for human consumption. The name attribute is for human consumption and need not be globally unique. OASIS had this mix-up between the need for a unique ID (for internal machine use) and the need for a human friendly name or label (not necessarily unique). > > > The alternate approach is to use URN:reference, > which since URN is unique will net a GUID that is > referencable. The uri attribute's purpose is "Object Location" and retrieval while the guid attribute's purpose is "Object Identification" (and name attribute's purpose is "Object Naming"). The same object may theoretically be locatable by more than one URI. In contrast there exists only one GUID for an object. > > > 128 random numbers are convenient for machines but > do not meet our business need - most clearly since > inspection of the GUID does not indicate any ownership. That is quite OK since a GUIDs purpose is not to indicate ownership. > > > The model I am preferring is the BARCODE model, EAN > and UPC - we should look there for inspiration, and also > be mindful of the STEP and CALS/UDEF and > EDIFACT work on GUID schemes. > > Notice also - the use of the word RECOMMENDED is > probably OK - but some may prefer qualify this by saying > DCE 128 / or / - and then list alternates based on business > use case need. > I had made no recommendation in earlier versions. I had made the recommendation verbally and in email to TA as a ebXML wide GUID scheme standardization suggestion. I was asked at Tokyo to mention the recommendation so I did. I believe there should be one recommended GUID scheme (that was the whole idea behind a recommendation in the first place). > > DW. -- Regards, Farrukh
begin:vcard n:Najmi;Farrukh tel;fax:781-442-1610 tel;work:781-442-0703 x-mozilla-html:TRUE url:www.sun.com org:Sun Microsystems;Java Software adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA version:2.1 email;internet:najmi@east.sun.com fn:Farrukh S. Najmi end:vcard
Powered by
eList eXpress LLC