[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Counter Offer Suggestion 1.: [ebxml-cppa-negot] message contentversion 09062002
Some comments within.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Dale Moberg"
<dmoberg@cycloneco To: Robert D Kearney/Watson/IBM@IBMUS,
mmerce.com> <ebxml-cppa-negot@lists.oasis-open.org>
cc: Martin W Sachs/Watson/IBM@IBMUS, Heiko Ludwig/Watson/IBM@IBMUS
09/16/2002 01:35 Subject: RE: Counter Offer Suggestion 1.: [ebxml-cppa-negot] message content
PM version 09062002
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.
MWS: I agree.
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.
MWS: I agree. The spec. has to make this clear.
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.
MWS: I don't think that we have really considered these points yet. I have
been working on the assumption that the current consensus is that one
negotiation dialog works with the NDD and draft CPA (CPA Template) offered
by the party submitting the initial offer. I suspect that allowing the
countering party to submit its own NDD and CPA Template with a counter
offer will add considerably complexity. Of course the countering party can
do a complete reject and then submit its own initial offer starting a
new negotiation dialogue.
MWS: It occurs to me that allowing the countering party to submit its own
NDD and CPA template could violate Dale's rule (above): A CounterOffer
should not constitute a wholesale change of subject .
MWS: I have some text in the draft specification to the effect that if
a party that intends to make an offer has access to the other party's
NDD, it might wish to build a new NDD that covers what is negotiable
in the two original NDDs.
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.
MWS: While we have come a long way from the original BPSS proposal, which
was mostly a "take it or leave it" negotiation, we should be concerned
about
adding complexity that might get in the way of having something ready for
submission by the end of December.
</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.
MWS: True. See my comment above.
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.
MWS: Yes, this is a proposal that the edit history remain in the
negotiation message. The main difference from what we have been talking
about is that Bob want to include the entire edit history, not just
what was accepted from the previous counter offer.
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.
MWS: My personal opinion is that this is one designer's
view of reducing complexity. I will await Bob's response.
</DM>
All the time for reactions to the first point. I hope to comment on your
other interesting suggestions later this week.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC