Re: [ebxml-cppa-negot] Re: AW: [ebxml-cppa-comment] AW: Re: [ebxml-cppa-negot] Issues forDiscussion: templates and dummy values

[Martin Sachs <msachs@cyclonecommerce.com>]

Here are a few replies:

We have always intended that a CPP be valid whether or not it has an 
associated NDD.  The CPP describes its owner's characteristics and should 
always be valid (with real values) since it may be used by some party that 
doesn't intend to negotiate. The NDD indicates which elements and 
attributes in the CPP could be negotiated. Sacha describes these issues 
very well below.

Regarding item (a) under "In the CPA Template...": Remember that our 
current direction is that a CPA Template MUST be able to be validated using 
the CPPA schema. That means that a CPA Template shall not have elements or 
attributes for which values are required but have no values (or no 
lower-level elements in the case of an element). An element or attribute 
may be omitted only if its cardinality includes "zero".

Regarding "Maybe it would be even clearer to have a state to indicate that 
a party (in the dominating scenario) does not want to
negotiate at all ...":  If a party does not want to negotiate, the party 
should not publish an NDD with its CPP. If another party anyway requests 
negotiation, the first party can reject the request. It isn't obvious to me 
that we need a separate state indicator along with the presence/absence of 
the NDD. The first party can create a CPA from its and another party's CPP 
without considering it a template.  The other party can accept or reject 
but that's all.  A fair question would be:  shouldn't all parties be 
prepared to negotiate since except for the simplest cases, there can always 
be some issue to resolve. The answer is, of course, "yes" but some parties 
may prefer to negotiate by phone rather than by computer.

An optional NDD element with Xpath expressions to the "dummy" elements and 
attributes is probably the simplest change to make but it is not 
necessarily the simplest for someone to use. In any case, the CPPA schema 
will still have to be modified to incorporate that NDD element. How to 
validate the contents of that element is another matter.

I would like to caution everyone that it is a bad idea to be too ambitious 
at this stage since the SC has a small number of active members.  We should 
be working on the goal of simplifying what we have and leaving major 
improvements to a future version.

Regards,
Marty

At 11:36 AM 9/15/2004, Sacha Schlegel wrote:
>Hi Michael
>
>Am Mittwoch, den 15.09.2004, 16:41 +0200 schrieb Vetter, Michael:
> > Hi Sacha
> >
> > You do not need to convince me of the use of NDDs for negotiation.
>
>So do you see the current approach with
>
>a) NDD_CPP's as a way to indicate what a party wants to negotiate in
>their CPP and
>b) the NDD_CPA_template as a way to indicate what two parties can
>negotiate in a CPA negotiaiton
>
>as applicable?
>
>Question: Is a CPP which has an associated NDD_CPP valid?
>Question: Could a CPP which has an associated NDD_CPP be invalid? A CPP
>template?
>
>So far I always thought of the CPP being valid and complete and the
>NDD_CPP just adding (negotiation) information.
>
>For the records: A final, signed, ordouble-signed CPA has no NDD at all.
>
>So the situation between CPP and NDD_CPP and CPA template and
>NDD_CPA_template is slightly different. The main difference is that the
>CPP's are complete and the CPA template is incomplete. The
>NDD_CPA_template as well as the NDD_CPP add (negotiation) information.
>
>In the CPA template case we want to use the negotiation information to
>
>a) indicate what values are dummy values or empty values or missing
>elements/attributes in the CPA template
>b) to indicate what possible values those elements/attributes could have
>
> > I just focussed on dummy values and templates.
>
>My problem was that the CPA template from a CPA composition cannot be
>validated.
>
>I saw a need for a way, under the usage of use standard tools (XML
>schema validator, maybe XSL transformation tool), to be able to get from
>a CPA template with its NDD_CPA_template to a valid CPA.
>
>Question: is it realy necessary to get a valid CPA from a CPA template
>and NDD_CPA_template?
>Question: would be useful to have a CPA template in connection with its
>NDD_CPA_template which validates but is still just a mock up CPA?
>Question: What are the problems with the CPA template anyway ? :)
>
>Why did you focused on dummy values and templates?
>
>
> > I suggest the states {template, draft/proposed, agreed, signed, 
> double-signed} for a CPA. Whether it is "dominating" just depends on how 
> much one party is willing to negotiate (as indicated in the NDD).
>
>I tend to agree. Maybe it would be even clearer to have a state to
>indicate that a party (in the dominating scenario) does not want to
>negotiate at all just wants a complete CPA from a CPA template. In that
>case there would be the use case that a CPA template is invalid (empty
>elements/attributes for party info and endpoints, certificates etc) but
>has no NDD_CPA-template associated with it.
>
> >
> > I am not an expert on XML design. Maybe an single new element in the 
> CPA with a list of paths to dummy elements and attributes is more elegant 
> than the all the new *-dummy attributes.
>
>OK So I missunderstood you.
>
>Not clear what you mean with CPA here. I assume you are talking about
>the CPA template. So the CPA XML schema and CPP XML schema could have an
>optional NDD element which has n XPath expressions to the
>elements/attributes.
>
>A final, signed, double-signed CPA will have no such NDD element.
>
>Example:
>
><myelement/>
>
>Assuming this element is of a boolean type. But for some reasion there
>is no value set. So for my usecase (validation purposes) I would need
>something like:
>
><myelement>true</myelement> or
><myelement>false</myelement>
>
>But it would be not nice to put a random value into the CPA template ...
>could be too easy for someone to think that is the real value, so ...
>
><myelement>::dummy::</myelement>
>
>could be another approach. But this approach will not validate, as the
>value must be boolean, so ...
>
><myelement/>
>
>and as we have now in an external NDD (or could be an internal as you
>mentioned) we could have:
>
><ndd>
><negotiationInformationItem xpath="/myelement" type="boolean"/>
></ndd>
>
>this example without preferences.
>
>Something like this is what we have now.
>
>So I think it comes down to an XSL style sheet which takes the internal
>or external NDD information and transforms a CPA template into a
>possible CPA. Could this subcommittee come up with a generic XSL style
>sheet which transforms any CPA template with its associated
>NDD_CPA_template to a valid CPA?
>
>Possible CPA because myelement could be true or false.
>
>
>We should play through an example of an XML element which has child
>elemnt(s). Next we should play through an example with an attribute
>which dictates some structre of the document (encryption business
>integrity example from previous email).
>
> >
> > I would not use the term business rules here but rather integrity rules 
> or schema rules.
>
>Agree integrity rules is the better name.
>
>Regards
>
>Sacha
>
>
>
> >
> > regards
> >
> > Michael
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Sacha Schlegel [mailto:sacha_oasis@schlegel.li]
> > > Gesendet: Mittwoch, 15. September 2004 15:33
> > > An: Vetter, Michael
> > > Cc: Martin Sachs; ebxml-cppa-comment
> > > Betreff: Re: [ebxml-cppa-comment] AW: Re: [ebxml-cppa-negot]
> > > Issues forDiscussion: templates and dummy values
> > >
> > > 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.
> > > > >
> > > > >
> > >
> > >
> >

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