AW: Re: [ebxml-cppa-negot] Issues for Discussion: templates and dummyvalues

["Vetter, Michael" <Michael.Vetter@iao.fraunhofer.de>]

Hi Marty 

I have some comments on your discussion about templates and dummy
values. I think that adding an optional attribute "dummy value" to all
relevant items in the CPPA spec could avoid confusion and ease the
management of CPA templates with several NDDs. When a template is
created the elements that need to be included in a corresponding NDD can
already be marked in the CPA template. After creation of the NDD the
tags can be used to check automatically whether something has been
forgotten. When someone looks at the template he does not have to check
the NDD to detect dummy values. A system would have to parse the CPA
template anyway to check whether it conforms to his party's CPP. It
would no longer be mandatory to have a NDD for a CPA template that just
needs some party information to be filled in. The presence of dummy
values could also be used to check whether a CPA is still in template or
already in (acceptable) draft status. 

regards

Michael


> Subject: Re: [ebxml-cppa-negot] Issues for Discussion
> 
>     * From: Martin Sachs <msachs@cyclonecommerce.com>
>     * To: "Kartha, Neelakantan" <N_Kartha@stercomm.com>
>     * Date: Thu, 09 Sep 2004 15:12:30 -0400
> 
> 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-beco
> me-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.
> 
> >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.
> 
>