Re: [ebxml-cppa] A big issue

[Christopher Ferris <chris.ferris@sun.com>]

Duane,

I'm not convinced that a "registry centric view of
operations" is necessarily a "good thing(tm)".

I believe that there are many who believe that
the registry has a primarily a design-time usage.

That said, I believe that the appropriate usage of
the UUID identifier of a BPSS instance would be
with the xlink:role attribute, which appears to
be absent from the xlink.grp definition.

I do feel strongly that a) the registry/repository should
provide for URI resolution of artifacts stored within
and b) that any runtime retrieval/resolution of
artifacts such as the BPSS instance should be accessible
via web protocols. I think that adding in the complexity
of having to use a registry API.

Cheers,

Chris

Duane Nickull wrote:

> Guys:
> 
> I found something else that is contrary to establishing a Registry
> centric view of operations.
> 
> In the 1.05 document, it states:
> 
> "7.5.4 ProcessSpecification element
> The ProcessSpecification element provides the link to the
> Process-Specification document that defines the interactions between the
> two Parties.  It is RECOMMENDED that this Business-Collaboration
> description be prepared in accordance with the ebXML Business Process
> Specification Schema[ebBPSS]. The Process-Specification document MAY be
> kept in an ebXML Registry.
> 
> NOTE:  A Party MAY describe the Business Collaboration using any desired
> alternative to the ebXML Business Process Specification Schema. When an
> alternative Business-Collaboration description is used, the Parties to a
> CPA MUST agree on how to interpret the Business-Collaboration
> description and how to interpret the elements in the CPA that reference
> information in the Business-Collaboration description.  The affected
> elements in the CPA are the Role element, the ActionBinding element, and
> some attributes of the BusinessProcessCharacteristics element.
> 
> The syntax of the ProcessSpecification element is:
> 
> 	<tp:ProcessSpecification 
>     tp:version="2.0"
>     tp:name="PIP3A4RequestPurchaseOrder" 
>     xlink:type="simple" 
>     xlink:href="http://www.rosettanet.org/processes/3A4.xml" 
>     <ds:Reference ds:URI="http://www.rosettanet.org/processes/3A4.xml">
>         <ds:Transforms> 
>             <ds:Transform 
> ds:Algorithm="http://www.w3.org/TR/20002001/REC-xml-c14n-20010315"/> 
>         </ds:Transforms>
>         <ds:DigestMethod 
>             ds:Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>         <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
>     </ds:Reference>"
> 
> <SNIP>
> 
> I believe that this is not the best solution.  The BPSS should be
> referenced via its' UID, not an xlink.  This allows applications to
> recognize it based on that unique value.  At Design time, this is a
> valuable feature.
> 
> A fixed link is also not the best way to do anything.  Links break. 
> ebXML has designed a Registry for this purpose.  
> 
> Another problem with this is that the Discovery phase relies on this UID
> for discovery. 
> 
> I strongly advocate replacing this with a UID.  Let the physical
> location reside in the "extrinsicURI" attribute of the RIM where it was
> designed to go.
> 
> Duane Nickull
> 
>