[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [ebxml-cppa-comment] AW: Re: [ebxml-cppa-negot] IssuesforDiscussion: templates and dummy values
Hi Sacha
You do not need to convince me of the use of NDDs for negotiation. I just focussed 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 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.
I would not use the term business rules here but rather integrity rules or schema rules.
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.
> > >
> > >
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]