Re: [ebxml-cppa-negot] Future document

[Sacha Schlegel <sacha_oasis@schlegel.li>]

Hi Marty

On Sun, 2003-11-09 at 12:16, Martin Sachs wrote:
> I have just placed the futures document in the document folder on our Web 
> page.  the zip file includes both the Word and the PDF files. Please 
> comment with reference the line numbers in the PDF so that the line numbers 
> are the same for all of us.
> 

Ooops just read it (concerning line numbers) too late.

Please find attached a notes file I wrote. It is rather general thoughts
than specific line number comments.

Regards,
Sacha


> Regards,
> Marty
> 
> *************************************
> Martin Sachs
> standards architect
> Cyclone Commerce
> msachs@cyclonecommerce.com 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php.
-- 
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
4 Warwick Str, 6102 St. James, Perth,  Australia
sacha@schlegel.li                www.schlegel.li
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------
Suggested Future Enhancements to CPPA Negotiation Specification
---------------------------------------------------------------

Comments from Sacha Schlegel
Comment: this comments come from a quick look at the suggestions.

1. negotiation protocol

1.1 negotiation directly with CPP's. Actually I did not think of this variant at all. Might be interesting as a negotiation algorithm at both ends could go sequentially (from higher level (party info) to lower level (DeliveryChannel, transport, docExchange, packaging down to simple part) through the elements of the CPP. Instead of 1.1.2 step 2 (one party creates CPA template) they could create the CPA (template) step by step (sort of element by element). Both sides would have to know pretty well how to form a CPA.

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.

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.

1.5 I came across this one as well. It can also happen, that one party sends an accept message even though there are still open negotiation items in the NDD. This is probably against the negotiation protocol (negotiation rules) and the receiving party will return with an error message. According to the BPSS an accept message can be sent no matter if there any open issues.

1.5 But I agree that there might be a message back and forth in the form of "we are done, what do you think?".

1.6 Ordering Dependencies among Negotiable Items. For some reasons I was believing that all Negotiation Items are negotiated in parallel. Have to recheck in the ANCPA.

3. Negotiation Algorithm - I start to have problems to see the border between the internal "negotiation" process and the collaborative negotiation business process. To which business process does the rules for the game, for example, once an item is accepted it is accepted belong to? The internal business process must know this rule, I think. If it belongs to the internal business process you/we might start to differentiate between these two business processes.

7. Simplification of Negotiation - You might provide a default negotiation algorithm specification/report which does only negotiate "simple" things. If there are simple things at all :)


Other questions/thoughts
------------------------

o Did you every think of not having everything negotiated in parallel? Unfortunately I did not think through an example but negotiating everything in parallel seems to be more difficult than negotiating one by one. As mentioned above I might have misunderstanding here.

o For some reasons I still think that when a negotiation starts both parties first have to agree on the CPA template and the NDD for that CPA template. Instead of having to reject and restart a new negotiation some Business Transactions Activities could be added to cover a "setting" stage first. Saying that, the acceptance of a CPA template and NDD might also end up in a offer - counter offer - counter offer scenario until the negotiation over the elements of the NDD starts.