Sachs 9/17/2002: [ebxml-cppa-negot] message content version 09062002

[Monica Martin <mmartin@certivo.net>]

On (2), this only will work in the context of Bob's responses, if we
understand which included items are open for negotiation (dependent
items that infer some order of negotiation - pre-requisites, perhaps).
On (3), I agree with your assessment.
On (4), I believe the end goal is to ensure that both parties have
complete understanding and acceptance, and the final CPA is sent.  I
would like to see if this holds up in a few business cases, before
commenting.

Thank you.
Monica J. Martin
Drake Certivo, Inc.
208.585.5946

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, September 13, 2002 12:37 PM
To: Robert D Kearney
Cc: ebxml-cppa-negot@lists.oasis-open.org; Heiko Ludwig
Subject: Re: [ebxml-cppa-negot] message content version 09062002






Please review and comment on Bob's suggestions below. Answers are needed
to
fill some gaps in our thinking.

Please note that Bob's (2) is a response to a counter offer that passes
initiative to the other party to send a counter offer.  This should be
able
to be handed in the same way as "Re-send prior offer" (see my  posting
earlier today) from a choreography viewpoint and can use the same
business
document name.

I believe that Bob's (3) requires a new status value in the negotiation
message that acknowledges that although the last counter offer is
accepted
in full, there are still open matters. Note that (2) is raising the
point
that dependencies among negotiable items may exist that require that
some
be settled before others can be considered.

 (4) May require additions to the BPSS instance. It means that the party
that sends the completed CPA has actually changed from our prior
thinking.
The sequence is:
1. A sends B a counter offer
2. B sends A acceptance in full
3. A sends B confirmation of the acceptance
4. B then sends the final CPA to A.
Previously, B would have sent A the final CPA in step 2.  If we agree
that
Bob's proposal simplifies management of CPA state, then the 4-step
ending
(5 if the CPA is signed) seems worthwhile.

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
************************************************************************
*************


 

                      Robert D Kearney

                                               To:
ebxml-cppa-negot@lists.oasis-open.org

                      09/13/2002 01:58         cc:      Martin W
Sachs/Watson/IBM@IBMUS, Heiko Ludwig/Watson/IBM@IBMUS                  
                      PM                       From:    Robert D
Kearney/Watson/IBM@IBMUS                                               
                                               Subject: Re:
[ebxml-cppa-negot] message content version 09062002(Document link:
Martin   
                                               W. Sachs)

 

 

 

 

 

 




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







----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>