[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [ebxml-cppa-comment] AW: Re: [ebxml-cppa-negot] Issuesfor Discussion: templates and dummy values]
Hi CPA Negotiation team Could not forward to ebXML-cppa-comment to I forward it to ebxml-cppa- negot Sacha -------- Weitergeleitete Nachricht -------- > Von: Sacha Schlegel <sacha_oasis@schlegel.li> > An: Vetter, Michael <Michael.Vetter@iao.fraunhofer.de> > Kopie: Martin Sachs <msachs@cyclonecommerce.com>, ebxml-cppa-comment > <ebxml-cppa-comment@lists.oasis-open.org> > Betreff: Re: [ebxml-cppa-comment] AW: Re: [ebxml-cppa-negot] Issues > for Discussion: templates and dummy values > Datum: Wed, 15 Sep 2004 15:33:28 +0200 > Hi Michael > > Thanks for your comments. > > First I think that the adoption of CPA's will take some more time (seems > like it gets a bit of a traction now) and I guess the adoption of > automated CPA negotiation takes even more time. > > Because of the theoretical adoption I am not sure if it would not > confuse people more if there is talk about negotiation dummy values in > the current CPPA specification. > > But I agree that the two documents (CPPA spec and ANCPA spec) need to be > better aligned. Maybe moving the CPA composition (Appendix E of the CPPA > spec) out of the CPPA spec and creating a new spec called "CPA formation > specification", which includes the CPA composition and the CPA > negotiation (what is currently in the CPA negotiation spec.) The CPPA > spec then could reference a new spec which talks about all aspects of > the CPA formation... > > Some further inline comments. > > Am Dienstag, den 14.09.2004, 16:42 +0200 schrieb Vetter, Michael: > > 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. > > Please correct if I am wrong, do you suggest to add a "dummy" XML > attributes and "dummy" XML attributes in the CPPA XML schema? > > Something like: > > <myelement name="testElement" isValid-dummy="true"> > <dummy/> > </myelement> > > This might polute the XML Schema of the CPPA ... > > In the current Automated Negotiation of CPA (ANCPA) spec there is a > section which lists elements and attributes which are negotiable ... > Actually I am not sure if that list is complete. It seems to me that its > quiet dynamic of what can be negotiated and what not. In the end alot is > negotiable ... > > I mean its obvious that the start and end elements should be negotiable. > My questions are rather if it is possible to dynamically (througout the > negotiation) add transportation elements, document exchange elements, > and more ... > > So far I had the impression that that is possible. Hence I see the > difficulty on both sides to actually "know" what it means to add a new > document exchange element or to modify an exisitng document exchange. It > will be very important that the parties add/remove/accept/modify > elements "correctly". And again it is not enough if in the end the CPA > conforms to the CPA XML schema. Rules not expressed in the XML schema (I > call them business rules) "must" be followed. As an example business > rule I use the case where we have an attribute set which says that the > document exchange must be encrypted but then the CPA does not have any > encryption information at all. It still would be a valid (against the > XML schema) XML file. > > I played little with schematron rules to test business rules and I think > that would be a way to at least check some aspects. Nothing worse than a > CPA that does not make sense. The ebXML messaging system would probably > choke on a XML valid but logically invalid CPA. > > I would like to see Schematron rules in the CPPA specification appendix. > Maybe once Schematron is an accepted ISO standard ... I opt to use as > much normative information as possible. > > > When a template is > > created the elements that need to be included in a corresponding NDD can > > already be marked in the CPA template. > > So in the example above: > > CPA template: > > <myelement name="testElement" isValid-dummy="true"> > <dummy/> > </myelement> > > You would know that there must be an entry in the NDD for isValid > attribute and the myelement element > > NDD-for-CPA-template (nii element ist just an example): > > <nii xpath="myelement"> > <option> > <value>5</value> > <value>10</value> > </option> > </nii> > <nii xpath="myelement[@isValid]> > <option> > <value>true</value> > <value>false</value> > </option> > </nii> > > > > After creation of the NDD the > > tags can be used to check automatically whether something has been > > forgotten. > > OK. > > What if the myelement has a complicated child element? Will you provide > an example complicated child element in the NDD? Probably not ... > Actually a good question. My impression was that if element X of the CPA > has child element(s) it is enough to reference element X in NDD to > negotiation X and all its children. > > One reason for me to ask for something like dummy values was to be able > to validate a CPA template against a) XML schema and maybe b) business > rules. > > In the X example it would not be possible to validate for either if > there is not a complete X element in the NDD. > > > When someone looks at the template he does not have to check > > the NDD to detect dummy values. > > Yes that would be the case. But looking at the CPA template alone it > would not show that a party would be willing to have alternative values > than those non-dummy values in the CPA template. > > > A system would have to parse the CPA > > template anyway to check whether it conforms to his party's CPP. > > Thats true. I get the impression this check will become crucial. It also > includes to check if it conforms to the other party's CPP and, if NDD's > were used, if the other party's and your NDD were taken correctly into > account as well. > > Such a check will become difficult. Another difficulty will be later > during the CPA negotiation to "correctly" fiddle with the CPA template. > > > It > > would no longer be mandatory to have a NDD for a CPA template that just > > needs some party information to be filled in. > > I think we should separate the original use of the CPA template (eg > dominating party fills out an CPA with open parts for the other party to > fill in). I could imagine that if a (dominating) party provides a CPA > template it could a) just leave out the party info plus endpoints and > not provide an NDD at all and not being interested at all to even > negotiate or b) limit the negotiation space to this one CPA template. In > such a CPA template they would not have taken any other party's CPP into > account at all. In that case the other parties NDD-for-CPP is worthless > too. > > Sorry if I mix up 2 different types of CPA templates and CPA draft. > > A good step is to explain the terminology again. > > > The presence of dummy > > values could also be used to check whether a CPA is still in template or > > already in (acceptable) draft status. > > This test could be to search for any <dummy> elements or any "*-dummy" > attributes in the CPA template. > > BUT still a party might want to have an NDD to express that it is > willing to accept other values. Eg there is a "true" in the myelemnt > element but in the NDD it also lists that it allows a "false" value. > > In the last phone conference it was discussed if a at the top level of > the CPA element could indicate the state of a CPA (final, dominating- > template, template). > > Regards. > > Sacha > > > > > > 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. > > > > > > >
Dies ist ein digital signierter Nachrichtenteil
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]