[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa-negot] message content version 09062002
The messages described in the formally attached seem reasonable, but leave a few points to ponder. My discussions with Marty encouraged me to post my questions here as food for thought. My principal thoughts involve the Counter Offer message (say, from party "A" to party "B"). I didn't see that the structure of the counter-offer message was completely defined, so I guess I'm free to make a suggestion or two (or four). 1. As I would like to see it, a Counter Offer message can contain an array of parts, each part with a form isomorphic to: XPath - a path to the item concerned; code - indicating whether the value as presented by the party "A" is being accepted by party "B"; or the item is being countered by party "B"; value - the value that was accepted, or the value being offered as a counter-offer. Note that this suggestion says that the accepted value, originally proposed by party "A" is returned to party "A". I find this convenient, since then party "A" does not have to keep track of the offers he has made; he can remain essentially stateless with respect to his offers. He updates his CPA only when he sees that party "B" has accepted is (counter-)offer. 2. Assuming (1), then a Counter Offer message consists of a mix of (zero or more) accepted parts and (zero or more) counter-offer parts. I feel that is should be permissible to have only accepted parts and no counter-offer parts, even if negotiation is not complete. Here's my reasoning. Party "B" may agree totally with a set of values submitted by party "A", but suppose not all values presented in the NDD have been settled. This can arise because of a dependence relationship: perhaps a set of items have to be resolved before others can be considered. The above situation, then, can mean party "B" is saying, "I agree with what you have proposed so far, now make a (counter-)offer on some items that, up until now, you were not able to consider." 3. Again, assuming (1), all values will have to make a "round trip", one direction where it is proposed, and the other where it is accepted. What happens to the value? Do the accepted parts remain in subsequent Counter Offer messages until all the items in the NDD are agreed upon (meaning the last Counter Offer message will have lots of accepted parts), or will the accepted part, having made the "round trip", be removed from future Counter Offer messages? I tend to prefer the former, because then a party knows when the negotiation is over by counting items in the Counter Offer messages. 4. When is the "CPA Offer Accepted" message sent? It seems quite simple to say it is sent by the party making the acceptance of the last counter-offer, but with the above assumption, it would be best sent when the last-negotiated item has made its "round trip" of offer/acceptance. That guarantees that both parties have seen all of the acception notices before a "CPA Offer Accepted" is transmitted. Bob Kearney Jean Zheng <jzheng@vitria.com> on 09/06/2002 07:58:27 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: ebxml-cppa-negot@lists.oasis-open.org Subject: [ebxml-cppa-negot] message content version 09062002 Here is the updated Message Content I have promised. I've gone through Marty's discussion with Bob and Monica regarding adding a "change list" to CPA template, and I have included a paragraph in section 1.1 that hopefully has captured your suggestions. Regarding what to include in the negotiation spec. I think we will probably follow the style of CPPA spec, where we have element by element descriptions of each item of message content. Or else, we can start with the current structure of this msg content doc. As we flush out more details, they will grow accordingly. What do you think? I will be working on the schema for the next few weeks. :) Jean
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC