RE: Counter Offer Suggestion 1.: [ebxml-cppa-negot] message contentversion 09062002

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Robert D Kearney wrote:

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

<DaleMoberg>
My picture of counter offers  (which 
may differ from other TC subteam members)
involved the following preconditions and
distinctive features:

First. CounterOffers occur after someone has initiated CPA Negotiation
by at least sending a negotiation message, a draft proposed CPA, and 
a NDD proposed as governing the proposed CPA.
 
Second. A CounterOffer should not constitute a wholesale change of
subject (refer to a different business process specification or
change the roles of the participants.

Third, a distinctive factor of the counter offer was that it could use
the NDD of the countering party. I am uncertain whether we have decided
to allow it to include a distinct draft CPA from the countering party,
but we had discussed this at one point.

What happens to the <xpath,code, value> list in this case is not
something
I have seen discussed, so your first point at least raises this question
and points out a need for more discussion.

Maybe we have shifted from these three points, but I would like to be
reminded why.
</DaleMoberg>

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

<DM>
I think we regard this as one form of a counter offer. But this way of
looking at it throws out the factor of introducing a new NDD. 

The "change list" message would be for minor negotiation points under
the first NDD. 

I am getting worried that we are not permitting the countering party to
ever propose its NDD.

Maybe we should distinguish a minor accepting counter offer (no change
of NDD
or reference draft CPA) from a major shift in counteroffer (with change
of
NDD and referenced draft CPA). 

</DM>
"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.

<DM>
Is this just a proposal that the "edit history" remain in the
negotiation message?
Last meeting we moved this list to the message itself, as I understand
it.

I think this design is not so much being stateless 
as allowing the history of edit
state to be synchronized between the participants. 
We should hope that the
participants are trustworthy and do not 
modify the "edit history" to their
advantage. Otherwise we might want the 
sides to trust but verify the
edit history each time.
</DM>

All the time for reactions to the first point. I hope to comment on your
other interesting suggestions later this week.