[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [ebxml-cppa-negot] CPA composition creates an NDD for the CPAnegotiation.
Forwarding a comment from Sacha. >Date: Sun, 18 Jan 2004 21:47:30 -0500 >To: Sacha Schlegel <sacha_oasis@schlegel.li> >From: Martin Sachs <msachs@cyclonecommerce.com> >Subject: Re: [ebxml-cppa-negot] CPA composition creates an NDD for the >CPAnegotiation. > >Hi, Sacha, > >I have a few responses. See below (MWS:). > >Regards, >Marty > > >At 03:24 AM 1/19/2004, Sacha Schlegel wrote: >>Hi Marty >> >>On Sat, 2004-01-10 at 23:09, Martin Sachs wrote: >> > Hi, Sacha >> > >> > Before I look at your scenario in detail, you need to clarify >> > something. >> > >> > Are elements, X, Y, W, and Z instances of different elements or are >> > they instances of the same element in the different documents, >> > Obviously, Y and W are different elements since both are in NDD-CPP-B >> > but it is not clear about X and Z. >> >>Sorry for the confusion, I started off with one example and then added >>more examples into it. >> >>I send you the corrected example, in a new email. >> >> > >> > I believe that you have uncovered an important oversight regarding >> > whether a party does not provide an NDD at all. I believe that our >> > intent has been (and the draft specification states) that not >> > providing an NDD leaves another party free to state (in the NDD-CPA) >> > what it wants to negotiate. >> >>OK. >> >> > I do not believe that we define how a party indicates that it does >> > not want to negotiate anything. >> >>OK, this the question then. What can a party do to say, that there is >>just no negotiation about its CPP. No negotiation about any >>elements/attributes. A clear take or leave it. > >MWS: See below. > > >> > I don't think that we should require that an empty NDD should be >> > published. >> >>Agree, an empty NDD would be of no value. >> >> > That would require every CPP to be accompanied by an NDD. It would >> > not be backward compatible to today. I think that the rule should be >> > that no NDD means no negotiation. >> >>That would also mean that the NDD must be very easy to find, otherwise >>it would mean that there is no negotiaiton. "Very easy to find" is maybe >>not that easy. If it includes to make another query (to ebXML >>Registry/Repository, or company) new parameters have to be set. This >>introduces again some more complexities. > >MWS: I believe that the model of a Registry entry that we have in mind >contains >pointers to the CPP and 0 or more NDDs (and probably other kinds of >information >as well). So, finding each NDD should be no more difficult than following >(for example) multiple links on a single Web page. > >> > We could add an element to the NDD that specifies one of these >> > choices: >> > >> > 1. Contact me to discuss what is negotiable >> > 2. Everything in the CPP is negotiable >> > 3. Negotiable items are defined below. >> > Alternatively, we could leave out (3) since if there is anything else >> > in the NDD, those are what is negotiable. >> >>This would mean at least one NDD for each CPP. Have you thought about >>the scenario, when a party has more than one NDD for a CPP? > >MWS: See my comment directly above. Finding each NDD should not be >difficult. One could also image that with each NDD pointer is a brief >description of what's in it, so that it should not be necessary to examine >each NDD in detail. > >MWS: A possible futures item is to provide a recommendation for the >structure of the part of a registry entry that has pointers to its CPP and >NDDs. > > >> > However, I'm not sure that XML Schema provides a way of stating that >> > the cardinality of an element is 1 if it is the only element in the >> > document, and zero if there is anything else in the document. >> > >> > When you clarify whether X, Y, Z, and W are instances of the same or >> > different elements, I will take another look at your scenario. >> >>Will resend you the example in another email. >> >>Kind regards >> >>Sacha >> >> > >> > Regards, >> > Marty >> > >> > At 03:57 AM 1/10/2004, you wrote: >> > > Hi CPA negotation group >> > > >> > > Here the scenario which leads to a question: >> > > >> > > Assuming that two parties have a CPP as well as an NDD for their >> > > CPP. >> > > >> > > * CPP-A with NDD-CPP-A (CPP and NDD for CPP of party A) >> > > * CPP-B with NDD-CPP-B (CPP and NDD for CPP of party B) >> > > >> > > * Simplified NDD-CPP-A has one negotiation item, which deals with >> > > element X. >> > > * Simplified NDD-CPP-B has one negotiation item, which deals with >> > > element Y. >> > > * Simplified NDD-CPP-B has one negotiation item, which deals with >> > > element W. >> >>Element X, Y, W, and later Z are all instances of different XML CPPA >>leaf-elements or attributes (please do not consider non-leaf elements >>yet). >> >> >> > > >> > > The CPA composition process takes all 4 documents and tries to get a >> > > CPA. >> > > >> > > Lets say there is a problem in element W, X, Y and Z and the CPA >> > > composition cannot find a (simple matching) solution for those >> > > elements, >> > > even with the use of the NDD's. >> >> >> >> > > >> > > So the CPA composition process creates a CPA template and a new NDD >> > > for >> > > the CPA template, called NDD-CPA. >> > > >> > > In the NDD-CPA we suspect to find a negotiation item for element X >> > > and a >> > > negotiation item for element Y. >> > > >> > > The question is about the problem with element W and Z? >> > > >> > > First question: Can the CPA composition algorithm put a new >> > > negotiation >> > > item for element Z and W into the CPA-NDD? >> > > >> > > I am not sure how the specification deals with this problem. I think >> > > the >> > > specificiation rather points to the "no" way. I even think that the >> > > specification does not allow the element z in the NDD because one >> > > party >> > > does not want negotiate over it. >> > > >> > > Pro (yes - supporing thoughts): >> > > >> > > - element Z and W are problem cases and have to be dealt with to >> > > overcome these problems. Typically the CPA negotiation could help. >> > > - an entry in the CPA-NDD would indicate the problems and thus >> > > parties >> > > would not have to "search" for any problems again. >> > > - if there is no change over element Z or W, there will never be an >> > > agreement. >> > > - Long term the CPA negotiation might be used, as a first instance, >> > > to >> > > negotiate over any problems and human to human negotiation, as a >> > > last >> > > instance to negotiation over any problem. >> > > >> > > Con (no - non supporting thoughts): >> > > >> > > - element W is not listed in NDD-CPP-A so party A is not willing to >> > > negotiate over element W. >> > > - element Z is not listed in neither NDD-CPP-A nor NDD-CPP-B. This >> > > could >> > > be interpreted as: neither party A nor party B allow to negotiate >> > > over >> > > element Z. >> > > - if an element XYZ is not mentioned in a NDD-CPP, that party maybe >> > > cannot negotiate over that element, e.g. just does not have the >> > > negotiation algorithm for that item. So a negotiation over that >> > > element >> > > XYZ might be not possible. >> > > - Short term the CPA negotiation might concentrate on limited >> > > element/attribute negotiation. >> > > >> > > Second question: >> > > >> > > What if a party does not provide an NDD at all? Does this mean that >> > > the >> > > party does not allow to negotiate about anything, or opposite, that >> > > it >> > > allows to negotiate about anything. >> > > >> > > Please let me know what you think, or what the specification >> > > suggests. >> > > >> > > Kind regards. >> > > >> > > Sacha Schlegel >> > > -- >> > > ------------------------------------------------ >> > > Sacha Schlegel >> > > ------------------------------------------------ >> > > public key: www.schlegel.li/sacha.gpg >> > > ------------------------------------------------ >> > > >> > > >> > > To unsubscribe from this mailing list (and be removed from the >> > > roster of the OASIS TC), go to >> > > >> http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. >> > ************************************* >> > Martin Sachs >> > standards architect >> > Cyclone Commerce >>msachs@cyclonecommerce.com >>-- >>------------------------------------------------ >>Sacha Schlegel >>------------------------------------------------ >>public key: www.schlegel.li/sacha.gpg >>------------------------------------------------ > >************************************* >Martin Sachs >standards architect >Cyclone Commerce >msachs@cyclonecommerce.com ************************************* Martin Sachs standards architect Cyclone Commerce msachs@cyclonecommerce.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]