[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [ebxml-cppa-comment] AW: Re: [ebxml-cppa-negot] IssuesforDiscussion: templates and dummy values
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.
> > > >
> > > >
> >
> >
>
Dies ist ein digital signierter Nachrichtenteil
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]