OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-negot message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-cppa-negot] Message Content Update Mar. 20, 2002


Title: RE: [ebxml-cppa-negot] Message Content Update Mar. 20, 2002

     As Jean pointed out in the Message Content Update document, the "Offer CPA" Business Transaction and the "Counter Offer CPA" Business Transaction are practically the same thing (same pattern, same document, just different titles and swapped initating roles -- the Requesting Business Activity and Responding Business Activity are intentionally named the same thing).  The business collaboration protocol (figure 5) allows for the Offer CPA business transaction to follow the Counter Offer CPA business transaction.  Clearly this second (or Nth) Offer CPA business transaction is a counter offer to a counter offer.  I suppose instead of using the "Offer CPA" and "Counter Offer CPA" monikers, I could have used "Offer CPA From Party Initiating Negotiation" and "Offer CPA From Party Receiving The First Offer".  Likewise, the authorized roles could have been "One Who Initiates Offers And Responds To Counter Offers And Has Negotiator Privilege" and "One Who Responds To Offers and Counter Offers Has Negotiator Privilege."  I am thinking that Kevin Costner could have a role in our process.

Regarding having a special Initiate Offer business transaction:
     You know who initiated negotiation collaboration since it is obvious which party who sent the first CPA Offer message. So, the only reason to have a seperate initial offer transaction is if the business information is different than the business information in the counter offers.  It would appear that the current proposal is to have different information:

 > the initiating Offer is slightly different from
 > subsequence Offer and Counter Offer, where NDD and initial
 > CPA are sent and no "delta description" is needed.
     Note that due to the constraints imposed by the BPSS (and the UMM), if you add a special Initial Offer business transaction, we'll just end up with three transactions.  For example, Initial Offer, Counter Offer, Counter Offer From Party That Sent The Initial Offer And Was Likely Having Trouble With Long Names.  I recommend we go change the BPSS to make things work a bit more sensibly.  I'm going to try to do this.

Regarding seperate Offer and Counter Offer Documents or Counter Offer Indicator/Status
     There is no need to indicate that something is a counter offer since it is simply known: the first transaction is the offer and every transaction after the first that attempts to negotiate the contents of the orginal offer or a counter offer is simply a counter offer.  Yes, this means the possibility of NDDs every time.  If that is not desired, put a field in the Offer CPA document that says "Only I'm Allowed To Provide NDDs -- Call Me On The Phone If You Wish To Discuss".  We could add semantics to the business process models that state all NDDs in a collaboration must be a subset of the previously occuring NDD (which should give you convergence).

     I hope everyone realizes that in the CPA Simple Negotiation Business Process Model, version 0.06, that I intended every offer or counter-offer to simply be an offer (with a minor twist).  The two transactions ("Offer CPA" and "Counter Offer CPA") always exchange a "functionally complete" CPA. You might ask, "How is this different than just having a collaboration with a single Offer CPA that results in just Accept or Reject?" :^)

Regards,
Brian "Dances With Metamodels" Hayes
:^)

Disclaimer
        I'm just an engineer and analyst.  Every think I know about negotiation may not be true; but, I like to think it is.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC