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

["Kartha, Neelakantan" <N_Kartha@stercomm.com>]

Hi Jean:

Here are a few responses (with <kartha> </kartha>).

Regards,

Kartha

-----Original Message-----
From: Jean Zheng [mailto:jzheng@vitria.com]
Sent: Tuesday, November 19, 2002 10:00 PM
To: Kartha, Neelakantan; ebxml-cppa-negot@lists.oasis-open.org; Martin W
Sachs
Subject: RE: [BULK] - [ebxml-cppa-negot] Comments on negotiation
messages


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.
<kartha> There is a new typo near line 91: One REQUIRED ExpirationDate
element that ..

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).

<kartha> o.k </kartha>

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.

<kartha> Yes, I had realized that 167-172 explains it further. What I was
suggesting was the alternative (namely, items that have been accepted by
both parties) might
be better
</kartha>

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.

<kartha> I agree that xpath is precise enought to identify the exact
element. What I was suggesting that we need also additional information,
namely the value of that element. Or are you saying that the latest value is
going to be included in the 
CPA?
</kartha>

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

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.
<kartha> This comment was not clear to me </kartha>

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.
<Kartha> But what if ExpiratatioDate element is of type DateTime? There are
no
individual elements called ExpirationDate/Date?

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].
<kartha> Sorry, still not clear to me. 
</kartha>
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?

<kartha> If they are nonnegotiable from the start, they can be specified in
the NDD.
However, I am considering the case, when they become non-negotiable after
doing
the negotiation process for some time. Note that we consider that the NDD is
fixed once the negotiation starts.
</kartha>

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.

<kartha> If we require the parties to do it this way, you are right.
However, why should we force this restriction? Are you suggesting that
implementors could benefit from this?
<kartha>

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.
<kartha> I am suggesting that we should not recommend it. </kartha>


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