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
