RE: Negotiation problem

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Michael,

	please find here my comments.
Regards
/stefano

P.S.	Could you please keep all the relevant lists (especially TPA) in the
loop?


> -----Original Message-----
> From: Michael Joya [mailto:mike.joya@xmlglobal.com]
> Sent: 30 January 2001 20:55
> To: Stefano POGLIANI
> Cc: ebxml-poc@lists.ebxml.org
> Subject: Re: Negotiation problem
>
>
> >         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.

	None of them looks, to me, actually a discussion. They look more
	like "references" to the possibility of a bootstrap CPA, but both of
	them state that this is "work in progress"

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

	I haven't had time to read the RegRep specs so far. I will in the next few
	days

>
>
> >         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 makes you feel I said this?
	I said that a CPP points to the BP document because we were talking about a
	BP. Of course, the CPP may point to many BPs.

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

	There is a SINGLE CPA that is negotiated by the two parties.
	Let's take the simple case of two parties stating they support one BP (it
will be
	simple to extend to multiple BPs).
	The CPP of PartyA references the BP_Sell_The_Flowers. The CPP of PartyB
also
	references the BP_SellThe_Flowers.
	PartyA and PartyB negotiate ONE CPA.
	Your (2) (which says, if I am correct "The Respondant must calculate the
exact
	same CPA as her potential client") is improbable in the sense that there is
only one
	CPA

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

	Somebody from the BP team should comment on this.

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

	The activities of the CPA team are currently oriented in providing specs
	that would allow as maximum ease of implementation as possible.

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

	I do not, honestly. I think that once the CPA specs will be all finished
	it will be easier to understand, but I do not think that this will be
problematic.
	Of course, this is an opinion.
	Runtime compatibility will really be much more tricky!
>
>
>
> --
> // Michael Joya
> // XML Global Research and Development
> // 1818 Cornwall Ave. Suite 9
> // Vancouver, Canada
> // 604-717-1100x230
>
>
>
>