[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Name and GUID
Serm', On our last call before holidays - Dale summarized this all rather well - and assuming he still has the right notes - was going to publish a draft resolution on this for us. So - I think that is where this sits - and until we see that - I think we need to hold off on chewing this bone endlessly - because based on the discussion on the call - I thought we had this very close to resolution now. Thanks, DW ----- Original Message ----- From: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> To: "ebXML BP" <ebxml-bp@lists.oasis-open.org> Cc: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; "Nikola Stojanovic" <Nikola.Stojanovic@RosettaNet.org> Sent: Sunday, December 28, 2003 9:09 PM Subject: Re: [ebxml-bp] Name and GUID > > ----- Original Message ----- > From: "Dale Moberg" <dmoberg@cyclonecommerce.com> > To: "Monica J. Martin" <Monica.Martin@Sun.COM>; "David RR Webber" > <david@drrw.info> > Cc: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; "Jean-Jacques Dubray" > <jeanjadu@Attachmate.com>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>; > "Nikola Stojanovic" <Nikola.Stojanovic@RosettaNet.org> > Sent: Sunday, December 14, 2003 7:49 PM > 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... > > Serm> Does this mean that the BPSS Objects which will be registered in the > ebRS, their ID's must be equivalent to UUID? For example, BTA may not be > directly registered in the ebRS so it does not have an ID which is > functionally equivalent to UUID? </serm> > > > * 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]