ebxml-regrep message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: GUID: Registry Information Model v0.41


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.


org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh S. Najmi

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC