[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa-negot] Negotiation Message Content
Jean, I understand your point about CPA ID. If we do not pass the CPA-under- construction with the negotiation messages, we should explain this point in the spec. If we rely on each Party to separately keep track of the changes to the CPA-under-construction instead of exchanging the CPA on each iteration, we will definitely need to add a final exchange in which one Party passes the completed CPA to the other party for inspection before concluding the negotiation. This exchange is similar to the initial offer exchange and will have to be added to the "Successful" exits from the nested binary collaboration that choreographs the counter-offer exchanges. I do not believe that we have decided whether or not to pass the CPA-under- construction each time. I hope that we will start having enough people participating in the listserver discussions and on the calls to be able to make decisions and have confidence in them. 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 ************************************************************************************* "Jean Zheng" <jzheng@vitria. To: Martin W Sachs/Watson/IBM@IBMUS com> cc: <ebxml-cppa-negot@lists.oasis-open.org> Subject: RE: [ebxml-cppa-negot] Negotiation Message Content 08/13/2002 02:07 PM Marty, Thank you very much for your comments. I've updated the message content based on your suggestions except the CPA ID part. I assume that after the initial handshake no party needs to pass around the CPA document at its entirety. Having the CPAID in the message is easier for both party to look up the actual CPA document stored in some temporary store. Does that make sense? Have we decided that CPA Doc will always accompany all transactions throughout any one Negotionation dialog? Thanks, Jean -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Monday, August 12, 2002 8:01 AM To: Jean Zheng Cc: ebxml-cppa-negot@lists.oasis-open.org Subject: Re: [ebxml-cppa-negot] Negotiation Message Content Jean, Thank you for updating the message document. You have made a big step forward. Some comments: 1.1 Message Content I suggest avoiding the use of conversationId at the application level. A non-ebXML messaging service might not have a place in its headers for conversationId. Also, depending on system implementation, the value of conversationId might not be available to the application. The identifier of the particular negotiation dialog should be an application-level construct. For clarity, I suggest using a term that includes the word "negotiation" such as negotiationDialogId or negotiationInstanceId. 1.2 CPA ID Let's avoid the term "CPA ID", since cpaId is an attribute within the CPA and is defined as the ID of a completed, agreed CPA. We should identify the CPA under negotiation by a separate identifier that is carried in the messages. We could simply identify the CPA under negotiation by the threadId, negotiationInstanceId, negotiationDialogId, or whatever term we pick. There may be some advantage for future enhancements in keeping the ID of the CPA under negotiation separate from the negotiation dialog Id. 1.3 Offer and Counter Offer Paragraph 1: In Hima's BPSS instance, both Parties are sending Counter Offer documents once the original offer has been sent from Party A to Party B. So, I favor your Choice 2. Last sentence of "Choice 2": I believe that Hima's BPSS has more function than the one in "CPPA Simple Negotiation Model v 0.06". For now, I suggest that Hima's BPSS be the baseline for our work. We will eventually need to decide what material from "v 0.06" will be useful in the negotiation specification. Last paragraph: I agree with this paragraph but we should not encourage this behavior since it can lead to deadlock. I suggest that the specification recommend human to human contact following a "CPA Offer Rejected" message. 2. CPA Offer Expired We can either add this as a new message in the BPSS instance or we can make it a reason code on the "CPA Offer Rejected" message. I prefer to treat "Expired" as a reason code rather than a separate message. Scenario: This scenario can lead to both Parties sending a message at the same time (Party B sends its response to the offer or counter offer "a little late" just as Party A is sending its "expried" message). I prefer the scenario that you describe in the last paragraph of this section. However it still has a possible problem with Party A sending a reject to Party B's late message. This would probaby require adding an additional Business Transaction for this purpose. We will also have to specifiy something about dealing with the case where Party B "never" responds to the Party A's counter offer. 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 ************************************************************************************* Jean Zheng <jzheng@vitria. To: ebxml-cppa- negot@lists.oasis-open.org com> cc: Subject: [ebxml-cppa-negot] Negotiation Message Content 08/08/2002 07:58 PM Hello Everyone, After browsing through the CPPA Negotionation progress (Thanks Marty for the suggested reading materials!) during the past three months+, I've made some minor changes to the Message Contents based on Brian Hayes suggestions in March, such as changing Header/Payload to Business Information/Business Documents. I think this is still compatible with Hima's sample.xml. However, since Hima will go through his xml files with us on the next conference call, I will make more updates after that. I will mapped the message content into xml schema format once we are confident that this doc has captured 90%+ of the required elements during negotiation process. <<NegotiationMessageContent.doc>> Cheers, Jean #### NegotiationMessageContent.doc has been removed from this note on August 12 2002 by Martin W Sachs #### NegotiationMessageContent.doc has been removed from this note on August 13 2002 by Martin W Sachs
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC