Re: [ebxml-bp] Name and GUID

["David RR Webber" <david@drrw.info>]

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.
>
>
>
>
>
>
>
>
>
>
>
>