[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] Name and GUID
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]