RE: [BULK] - [ebxml-cppa-negot] Comments on negotiation messages

[Jean Zheng <jzheng@vitria.com>]

Kartha,
Thank you very much for the comments!

Please see my answers below with leading <jean>.

Marty, would you mind to help me to turn the word doc into a pdf?  Thank you.

I will incorporate changes/suggestions from Dale and Marty during the Thanksgiving break.  And I won't be able to attend the conference call tomorrow.  Sorry.

--------------------------------------------------------

74:  Typo inresponsTo
88:   Typo:  RespondingParty
90,91:    Add one line of explanation here also.

<jean> fixed in the attachment.

Currently, the messages do not contain references to the NDDs of  the two CPPs. I think that the messages should include these and also references to the  two CPPs that were used composing the draft CPA. They could all be included  under BusinessDocuments element (possibly as optional elements).

<jean> will fix this later when I fix the schema based on Dale's request to add in a ResponseToURL (0:1).


In the InitiatingParty and RespondingParty elements, the CPPId elemenet refers to the location of CPP, right? Please clarify.

<jean> No.  Currently CPPId contains an identifier and version.  No location is specified.

147: BusinessDocument elements: Are you saying that in the case of a CPA template, there is no need for an NDD? Could it be the case that even in the CPA template, some parts are negotiable? Or are we not considering that possibility for version 1?

<jean> My understanding is CPA Template is used in the situation of "take it or leave it".  If any of the elements is negotiatable, then CPA+NDD format should be used.  Dale could probably clarify more here.

152, 155 Fix these lines (maybe change . to a comma)
<jean> done.

174: Should Accepted Items be the items that have been accepted  by both parties in the
        process of exchanges  prior to this message?
<jean> no.  Please see line 167-172 in your current pdf file for clarification.

177: Don't we need an entry for the accepted value corresponding to the xpath?
<jean> in general, xpath is rather precise.  It can uniquely identify the exact location of any element in an xml file.  Personnaly, I think it is a little redundent to include the value also.

178: What is the meaning of "Deleted Items"? Items deleted from consideration of negotiation by the party sending the message? 
<jean> yes.

Here also, it seems as if we need to include the value, in addition to xpath. For instance, if an attribute x can have values a, b, and c,. we need to give the xpath to the attribute and then state that b is deleted. 

<jean> Deleted element is referring to an actual element in the "latest" copy of cpa I received.  It is very precise.  There shouldn't be any ambiguity, otherwise, it would be an invalid xml to begin with.  In other words, the element in question within the "latest" copy of cpa should contain either value a, b, or c, if all three are valid values as specified in the schema.

Does "deleted" mean deleted from consideration of negotiation for this round and all future rounds. If so, that should be stated in explanatory text.

<jean> Well, the other party might want to add it back in. If that happens, "I" can decide whether to stop the negotiation or to "reduce" the counter that indicating "convergence"?  It is up to the two parties that are doing the negotiation.

180: Inn updated items, there might not be a single original value of the item.. For instance, consider we are negotiating a start time. Then the original value might be a range of dates and updated values might be a smaller range of dates.

<jean> In your example, the ExpirationDate element can be listed as a list of xpath that each referring to an individual child element (leaf node). such as: ExpirationDate/Date; ExpirationDate/Year; ExpirationDate/Month. etc. etc.

184: What is the use case for inserted items? Clearly, the xpath must point to an item already present in the document. So are we saying that  we can have a new value?

<jean>  Same as in the programming world, insert element A[i] will mean the current A[i]->A[i+1].

It seems the facility to state that a particular value must be present would be useful. For instance, a party might want to state at some point in the negitiation that a particular value of an attribute is now non-negotiable (may be the choice has now narrowed, because of earlier choices). It would be good to add a flag (under, say, Updated items) to  ensure that this information can be carried along.

<jean> if any of the elements/attributes is non-negotiable, shouldn't that be specified in NDD?


189-191:  I think this restriction should go. Consider the case where a root element has a
negotiable attribute and three children. We might first negotiate the negotiable attribute and the root element and move it to accepted items. We might later negotiate the value of the sub elements.

<jean> Why not give the value now?  If the value is negotiable, the other party can provide a different one in the "updatedItem" section.  If it is not negotiable, it should be specified in the NDD already.

197-198: Repetition of the last two sentences. Using CPA Id as a negotiation dialog Id does not seem like a good idea. Consider the case that we use CPA Id as negotiation dialog Id and in which the negotiation fails. After human intervention, the negotiation starts again. We might wish to distinguish this new negotiation dialog Id from the previous negoitationi dialog Id, but cannot do it if we use the CPA Id.

<jean> That's why we said "could" be used as the dialog Id.  It is merely a recommendation.  The parties involved can decide what exactly to use for their dialog id.


200 Rewrite as:  Unique Business Message Id is a unique id ...

<jean> fixed.

203: Rewrite
<jean> fixed.

224: This section talks about only one scenario, but line 223 says two scenarios.
<jean> fixed.

231: Is the "shall" appropriate? What if the party does not have the ability to sign?
<jean> fixed.
--------------------------------------------------------

Cheers,
Jean
-----Original Message-----
From: Kartha, Neelakantan [mailto:N_Kartha@stercomm.com]
Sent: Wednesday, November 13, 2002 1:41 PM
To: ebxml-cppa-negot@lists.oasis-open.org
Subject: [BULK] - [ebxml-cppa-negot] Comments on negotiation messages


Here are the promised comments on the negotiation messages.

 <<Comments on the Negotiation Messages Section.doc>> 



Kartha

Attachment: MessageContent11192002.doc
Description: MessageContent11192002.doc