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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: AW: Core Component Analysis - SWIFT's Comments


Message text written by Andreas Schultz
> 
Hi all,

I agree with you all that we need a unique identifier for each entry, as we
discussed this already in Tokyo. As far as I understood TA and RegRep are
talking about a Global unique identifier which has a length of 64 digits
and
which is given automatically. We should think on having a UID different
from
that, with less digits, and which allows us to cluster entries in groups,
maybe similar the way we have this in the EDIFACT Data Element Directory.

Regards
Andreas Schultz<

>>>>>>>>>>>>>>>>>>>

Andreas - let me clarify this once again.

Internally within the registry - certain functions generate a 128 byte
reference.
This has been labelled GUID by Registry and also by Microsoft in their
explanation of GUID within a Windows OS Registry (run RegEdit on
your Windows computer and search for GUID!).  So as to NOT confuse this
with
the notion of GUID as intended in TA and elsewhere in ebXML - the term UID 
refers to a human readable reference.  This was well explained in the
earlier drafts of the TA doc - but was taken out as too implementation
detailed - but is nevertheless still required and well understood.

Of course for every UID, the Registry will generate an internal GUID.
However UID is just another element within content within the registry
(actually in the registry header to be precise) - so this ensures we
capture and expose thru the UI this important linkage detail.

Thanks, DW.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC