Re: [ebxml-cppa-negot] Issues for Discussion

[Martin Sachs <msachs@cyclonecommerce.com>]

Below are some replies to Sacha's comments.

Regards,
Marty

At 07:20 PM 9/8/2004, Kartha, Neelakantan wrote:
>Everyone,
>
>Here is a partial list of issues for discussion in the next call. All line 
>and section numbers refer to the pdf draft dated 11/2/2003 (attached for 
>your convenience). Come ready to discuss these during the next call!
>
>Best,
>
>Kartha
>=======================================================
>Issues:
>
>1.(From Sacha) There is no schema for a CPA template. What is a valid CPA 
>template? As once discussed a CPA only has one deliveryChannel element 
>whereas there can be more in a CPA template to keep the preference ... 
>Probably the CPPA schema is valid for a CPA template but ... not realy ... 
>Glossary says that a CPA template is a CPA with open fields, hence a CPA 
>template will never be a valid CPA. A CPA template cannot be validated, 
>can it? Maybe a CPA template does not have to be validated ...

MWS: It is intended that a CPA template conform to the CPPA schema. I 
believe that somewhere in the draft spec., it says that open fields must 
have values that enable the CPA template to be valid for the CPPA schema. 
The NDD indicates which values will be replaced by the results of negotiation.

>2. (From Sacha)  Line 250: I think the CPA should have an attribute with 
>possible values, such as "CPA template" or a "final CPA" or simply a 
>"temporary-test-something-that-looks-like-a-CPA-and-might-become-a-CPA".

MWS:  This might be useful.  This is primarily a CPA issue. If it is done, 
the negotiation spec. must include rules for changing the value of that 
attribute when the negotiation results in an agreed CPA.

>3. (From Sacha)  Line 286: I thought the term "draft CPA" should no longer 
>be used and the term "CPA template" should be used. Or a description of 
>what the difference is, if there is any anymore. Might have to be aligned 
>with the CPPA Spec and maybe the ebXML Architecture Spec. if not already done.
>Line 286: Section 6.2 only talks about CPA template, not one word about 
>draft CPA.

MWS: "Draft" is explained in section 6.1. The term is used in many places 
in the draft spec. Someone needs to review the use of the term "draft" 
throughout the draft spec. to see if the distinction between "draft" and 
"template" is meaningful.

>4. (From Sacha) x Line 294: A NCPA is for two specific parties, including 
>their party info etc, maybe highlight that a NCPA is a sort of a skeleton 
>CPA where the parties who want to negotiatiate just need to fill in the 
>parties specific information (eg party id). I think this has to be covered 
>somewhere ... like how the NCPA gets fully ready to be deployed...

MWS: The NCPA is not a skeleton.  It is a complete CPA that governs the 
exchange of messages during negotiation. The NCPA chapter definitely needs 
additional explanatory text, as is indicated in the italic comment at the 
beginning of the chapter.

>5. Should we make the distinction between real and virtual NCPAs (Line 
>416-417).
>Also, should we design an NCPA (Line 423)?

MWS:  Lines 382-387 are the important reference to "virtual". See also 
section 12.7 about NCPA simplification. The term "virtual" is introduced to 
take account of the fact that some pairs of partners configure their 
systems for message exchange without actually producing an XML document 
called a CPA. So the negotiating pair of partners might not actually have 
an NCPA instance document. This is part of the general problem that a lot 
of companies may use the ebXML message service without using a CPA. The SC 
may wish to review the continued importance of the distinction between real 
and virtual NCPAs.

>6. (From Sacha)  Line 429: Prior to this point, there is a very important 
>point in my opinion. The Initial Offer receiving party has to do a big job 
>here: validating the cpa template and the ndd! For this process it sort of 
>also has to create a CPA template and compare the two CPA templates if it 
>can agree to what will be negotiated. The same for the NDD, it has to make 
>sure it does not get cut short somewhere, that all its negotiation items 
>are fairly represented in the ndd which goes with the new CPA template.

MWS: I agree that it is important to make it clear that negotiation is 
non-trivial. I am not sure that section 5.2 is the right place to add this 
discussion though it might be the right place.

>7. Should we keep sections 5.4, 5.5 and 5.6 (or move it to futures?)

MWS: 5.4 and 5.5 are not futures items for the negotiation SC.  They are 
part of the background information for negotiation and belong here.  The 
tools mentioned in 5.4 are not a negotiation SC or OASIS matter at 
all.  They are implementation suggestions.
5.6 (Negotiation through an intermediary) is already in the futures 
document. It should remain here because it answers a question that will be 
asked by potential users of the specification. The futures document will 
not be released publicly; it is an internal working document of this SC.

>8. How would one distinguish dummny values from real values in in CPA template
>(line 515).

MWS:  Information in the NDD identifies those elements and attributes whose 
values will be replaced in the negotiation process. We should not attempt 
to add "dummy" indicators to the CPA.  That would add complexity to the 
CPPA spec. without providing new information that isn't already in the NDD.

>9. Do Start and End appear in the CPP? (Line 599)

MWS: the Start and End elements are in the CPA but not in the  CPP.  See 
the CPPA specification.

>10. Need explanation of sentence in line 628.

MWS: In this sentence, the term "function" means "element or attribute". 
The SC might want to replace "function" by "element or attribute".

>11. Need to unify sentences 620 (asnyc) with sentence 649 (sync).

MWS: 620 refers to ebXML message exchanges.  649 refers to what takes place 
in the underlying HTTP protocol. I suggest rewriting line 649 to make it 
easier to understand.

>12. What is the status of NCPA? Is there only one? A family?

MWS:  The only known NCPA instance document is the one in this 
specification. Its status is that work is needed (see section 8.5) to make 
it agree with the BPSS instance document in this specification and then to 
whatever form the BPSS instance document takes after the BPSS team 
completes its new version.  Each negotiating pair of partners will have to 
make some changes to the NCPA unless we can design one that works for 
everyone, as discussed in lines 627-630 and perhaps elsewhere in the spec.



>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. 
>

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com