RE: [ebxml-bp] Name and GUID

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

mm1: I believe in past ebXML discussions, GUID and UUID terminology, 
their differences by definition, or use have been discussed. To 
Farrukh's point and in the context of the ebBP discussion, we had four 
key goals:

    * To have elements unique within a package (at a minimum)

Dale> I think this means that distinct elements will have distinct GUID
values in their nameId attributes.
Using guids means that even when these elements are combined with other
BPSS instance elements, no collision will occur.
(even if they happened to have the same value for the name attribute)

    * To determine under what, if any circumstances, the GUID = UUID for
      key elements of the process description

Dale> not certain I understand this goal...

    * To enable the design process where the name is important
    * Differentiate computable reference of the process description and
      elements from their understanding by users (reference Yunker on
name)

Dale> OK

    * Determine if, and if so when, canonical names are needed

Dale> I hope we don't try to take this goal on (personal opinion).

I believe these goals are supported by many of the comments received 
thus far, and appear to be in concert with the ebRS and the eBA 0.83.

========================== General followup===========

Dale>

I am not sure how the registry, uuid, and guids have gotten mixed into
the original issues
about the internal uses of names and nameIds attributes using GUID and
GUIDREF datatype values.

In the ebBP specification the main reference to the registry seems to
be:
... (section 7.3)...
"the XML representation of the BPSS instance gets stored in the ebXML
repository and registered in the ebXML registry for future retrieval.
The BPSS instance would be registered using classifiers derived during
its design. 

When implementers want to establish trading partner Collaboration
Protocol Profile and Agreement the BPSS instance document, or the
relevant parts of it, are simply referenced by the CPP and CPA XML
documents. ebXML CPP and CPA XML documents can reference business
process specifications in XML such as an ebXML BPSS instance"

===============================

The use of classifiers in the registration process is not really
essentially connected to the original issues about name and nameId, as
far as I can tell. 

Registry RS 2.0 allows user clients to suggest a urn UUID to be used by
the registry. If that value is a legitimate one (something like
urn:uuid:[dce 128 bit token]), then it can be used. But I do not see the
ebBP specification suggesting/recommending/requiring that this be done,
nor Registry assuming BPSS instances are submitted in this "special"
way.

There is a ProcessSpecification attribute, ProcessSpecification/@uuid,
that does "identify" the instance to external users. (EG, the CPA uses
this value as the Service value for ebMS headers!) But this @uuid value
does not usually have the required Registry format, so I don't think it
would be used sucessfully when submitting an object to the Registry. And
this attribute is not really involved, I hope, in the name/nameId issues
originally raised.

If people think there are issues about the Registry, and uuid vs guid,
that is fine, but I am not clear myself what they are.

I would like to focus on the original issue, which I think was something
like the following:

It would simplify implementations, e.g., if nameID were always a way to
find the referred to object.

Perhaps there are reasons to not make this simplification. JJ advanced
one reason, pertaining to reuse.

I asked whether the substitution set mechanism could not be used for
JJ's purpose. Now maybe no one uses the substitution set (which raises
an issue about why retain it). But it seems to me that if we can
simplify some of the BPSS processing tasks without loss of
functionality, we should give serious consideration to doing that.