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


David:

I do not think we are disagreeing.  This approach does not "lock" them 
to ebXML Registry, just allows such. I have done nothing nor am I 
advocating doing anything that creates such a dependency.  I am working 
to make it possible in alignment with the charter and mandate of the 
OASIS CC-Review Sub TC and the spirit and intent of the ebXML TA and 
requirements.

I would envision that modellers will use the BIE's and CC's outside of 
the registry in most cases, but require access to certain bits of 
information within the registry.  In fact, collaboration on business 
models is a cornerstone of UMM, CCTS and BCM.   I would strive that we 
make every attempt to avoid constraining the BIE's and CC's and the 
methodology of UMM to be dependent on a registry, yet make it possible 
to do such.  It should also be possible to accommodate other registry 
UUID formats perhaps?

I have not confused UID and UUID.  They are not mutually exclusive as 
you correctly point out however, a UID that is not guaranteed to be 
universally unique is not acceptable as a UUID.  Therefore, the correct 
statement is that a UUID may be used as a UID, but a UID that is not 
guaranteed to be universally unique is not acceptable as a UUID.   A 128 
bit formatted DCE UUID is acceptable as both.  Since ebXML has already 
specified UUID in the 128 bit format, there is no point in discussing 
this further.

What I would support, reading between the lines of your email, is the 
use case for UID's other that the UUID to be present in a serialization. 
 This use case does have merit IMO and there may be an advantage for 
data transformation people to use more than one UID to help in mapping 
to internal back end systems data models.

The model can be flexible enough to allow support for other than ebXML 
registry alone.

I do not think you and I are disagreeing on anything are we?

Duane AA Nickull

(I added the extra "A" to be more like you ;-)

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com





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