Re: [ebxml-cppa-negot] Future document

[Martin Sachs <msachs@cyclonecommerce.com>]

My replies below (MWS2:)

At 07:18 PM 11/14/2003 -0700, Monica J. Martin wrote:

> > 1.2 Which BPSS Instance Document? Are you talking about the
> > Negotiation BPSS Instance document or the BPSS which are in the
> > parties CPP? I assume you are talking about the Negotiation Business
> > Process otherwise  if a CPA can have more than one CollaborationRole
> > per PartyInfo you might deal with more than one BPSS.
> >
> > MWS:  Yes, it's the BPSS in the Parties' CPPs.  The Negotiation BPSS
> > instance document can't be negotiated.  It defines the negotiation
> > protocol itself.
>
>mm1: Is this an item that should be addressed in collaboration with ebBP
>sometime in the future in v2?

MWS2:  If you are referring to negotiating the contents of the BPSS 
instance document for the business process that the two Parties want to 
perform, I guess that the BPSS team could consider it. To me it seems 
potentially very complex.  If you are referring to negotiating the contents 
of negotiation BPSS instance document, I don't recommend getting into the 
swamp of negotiating the negotiation protocol.


> >
> > 1.3 I thought that once you agree on an element you cannot change your
> > mind again might be a problem. Especially in case of interdependencies
> > (use case necessary in the way of if both parties do not talk about a
> > SecureTransport they cannot change the
> > BusinessTransactionCharacteristics
> > (isConfidentail,isAuthenticated,isTamperProof or
> > isNonRepduationRequired) attribute which asks for a SecureTransport
> > element). On the other hand this could be good as one party then is
> > assured, that once value is set it is set. Otherwise you might end up
> > in a loop, like in a game where both players repeat the same move
> > again and again because they think thats the only way to go.
> >
> > Might be difficult to provide a fair list which elements you allow to
> > renegotiate.
> >
> > MWS: You are exactly right.  That's why we now say "no going back".  I
> > will add your comments to the futures document.
>
>mm1: This brings up the point if they negotiate items that are in
>conflict with the assumptions in the BPSS instance document (for
>example, message level assumptions that may conflict with the business
>level definitions). I understand that CPP/A can override BPSS defined
>parameters, but what of the business agreement. Is this a potential work
>item for ebBP or between ebBP and CPPA (team and negotiation team)?
>Maybe I am misinterpreting?

MWS2:  Sacha and I were only talking about going back and renegotiating 
items in the CPA that had been previously agreed to within the same scope 
of negotiation. That is already discussed in the futures document and I 
will add Sacha's points to the discussion.

MWS2:  The potential trading partners must not put anything into their CPA 
that conflicts with assumptions in their BPSS instance document (other than 
the values of the overrideable attributes). I believe that this is in the 
area of validating the CPA against the BPSS instance document. That might 
be a good feature in a tools vendor's product. As to the business 
agreement, I agree that the CPA and BPSS instance document must be 
consistent with the higher level business agreement. Validating that 
consistency could be another value-add for a tools vendor, assuming that a 
specification for a machine-readable business agreement exists.

>I deleteted the balance of the document since there are no further MM 
>comments in it.

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com