Re: Negotiation problem

[Michael Joya <mike.joya@xmlglobal.com>]

>         I do not recall any public discussion on the "inducted bootstrap
>         CPA", but I may have lost it. Could you please point it to me?

http://lists.ebxml.org/archives/ebxml-transport/200101/msg00146.html
..in which Chris Ferris provides some clarity to myself over how the CPAId might
be calculated.

http://lists.ebxml.org/archives/ebxml-transport/200101/msg00144.html
...in which David Burdett outlines the notion of such a CPA document.

ebXML Registry Services Specification v0.83 lines 318-341
...whose sections read "Implicit CPA between Clients and Registry" and "Client to
Registry Bootstrapping".


>         In addition, I would think that the CPP (which "points" to the BP
>         document) is "normally" published in the RegRep.

  Thank you. I had the impression that the role of the CPP was to act as a
configuration document for a party to participate in ANY ebXML conversation. By
this new light, a party should have as many CPP documents as the number of
BP documents that it supports.


>         What do you mean by "proprietary BP document"?
>         In my understanding the BP document will be available in XML
>         form conforming to the Specification Schema.

  While the schema is staticly defined, its data is owned directly by an
organization. Sure, this is elementary. However, it highlights the improbability
of (2) from my original letter. Both parties must use this BP to influence the
creation of the CPA. This is not specified, nor is it easy to see whether that
should fall within scope of tp or bp teams.

   Is there a business process schema defined? I do not see it defined as a
deliverable on the ebXML BP project team page. I also have not seen such a
document instance produced by anyone in the POC team.


>         The use of "magically" does not reflect well the concept, I think.
>         Whilst (as Marty Sachs pointed out yesterday) it is not in the scope of
>         the CPA team to define the exact algorithm which defines the
>         composition, the CPA team will work in such a way that it will be
>         practical to derive the logical composition rules for the CPA
>         (not the algorithm)

  I use the term because I couldn't find that composition documented anywhere. I
would be just as satisfied with that as I would with the flat-out algorithm.
However, I can only implement that which can be verified by specification.
I envision this procedure as magical because it is non-trivial and unspecified. A
set of logical constraints documented in the specification would be a great
starting point for an implementor.

  Even armed with that verbal solution, I believe this negotiation process is
inherently problematic.



--
// Michael Joya
// XML Global Research and Development
// 1818 Cornwall Ave. Suite 9
// Vancouver, Canada
// 604-717-1100x230