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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: Re: [regrep] Summary: Issue with UUID's for Core Components and BIE's


Finally you have clarified the question you were trying to ask
(see bottom).

The mechanism you have described assumes you are using
CC and BIEs with an ebXML Registry.   This of course is only
one use case.

The use case I am focusing on is the broader one.  It does not
mandate the use of ebXML Registry - and provides support
for industry groups that may already have developed their
own CCs and codification schemes ( UDEF, RosettaNet, OAGi,
X12, CEFACT and more).

If you want to lock CCTS to ebXML Registry and UUID - then
what you are describing is an approach.

I however believe that the CCTS has not made this decision - 
and that the UID system (i.e. a human readable domain 
specific CODIFICATION system) is used to uniquely identify 
BIEs, CC and more equally applies and is being used.

The other clear fact is that UID and UUID are *NOT* mutually
exclusive - as you seem to want to constantly imply.  In fact
there are many business use case advantages to UIDs 
(which is why they are already widely defined) - that 
UUID does no have - whereas the UUID is a machine
level device for identifying content.

There is nothing to stop people using their own domain
UID system - and then if they want to import that into 
an ebXML registry - the external ID mechanism in the RIM
fully supports that today - and allows direct mapping
between UUID values and their domain UID values.

WRT - the ebXML Registry Versioning Support proposal 
further enhances the ebXML Registry ability to support 
the realworld use cases that we see from UDEF, RosettaNet,
OAGi, X12, CEFACT and more industry domains.

Mandating that CCTS BIEs require ebXML Registry will 
be counter productive longterm IMHO.  Ensuring that 
ebXML Registry can support broad general use cases
is the better approach.

Thanks, DW.
Message text written by "Duane"
>Aside from that, I believe personally that the CCTS is now 100% 
implementable.  The methodology has great value for all vertical and 
horizontal fields.  I do not see any major issues that would prevent it 
from being implemented within an ebXML registry.

I will incorporate this thread into the CC-Review work STC of the OASIS 
RegRep TC.

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