[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-cppa-negot] Re: AW: [ebxml-cppa-comment] AW: AW: Re: Automated CPA Negotiation
I have the following comment regarding the case that Michael mentions, namely "one CPPA element (referenced by an XPATH in the NDD) where the two parties have a common value range/enumeration but different preference functions. The negotiation problem here is to agree on one of these values." There are two cases: Case 1: Both parties are willing to let the other party see the preference function. (for instance, the individual NDDs are publicly available). In this case, since both parties know both preference function, including either preference functions in the overall NDD is not required. The schema caters to this possibility by allowing zero occurrences of the preference function. Case 2: At least one party is not willing to let the other party see the preference function. In this case, there is at most one preference function that is visible and that preference function can be included in the NDD. When the negotiation algorithm becomes sufficiently defined as part of the standard, in case 1, it might make sense to modify the schema to allow the possibility of both preference functions being included the NDD. Since we are quite a ways from defining the negotiation algorithms as part of the standard, it was felt that the current functionality is sufficient for now. Kartha -----Original Message----- From: Martin Sachs [mailto:msachs@cyclonecommerce.com] Sent: Wednesday, July 30, 2003 11:00 AM To: Vetter, Michael Cc: ebxml-cppa-comment@lists.oasis-open.org; ebxml-cppa-negot Subject: [ebxml-cppa-negot] Re: AW: [ebxml-cppa-comment] AW: AW: Re: Automated CPA Negotiation Michael, Thank you for the clarification. I agree that we need to work on this. Regards, Marty At 03:35 AM 7/30/2003 -0700, Vetter, Michael wrote: >Marty, > >I am not sure whether we are talking about the same case. >I meant one CPPA element (referenced by an XPATH in the NDD) where the two >parties have a common value range/enumeration but different preference >functions. The negotiation problem here is to agree on one of these values. > >Regards > >Michael > > > -----Ursprüngliche Nachricht----- > > Von: Martin Sachs [mailto:msachs@cyclonecommerce.com] > > Gesendet: Dienstag, 29. Juli 2003 22:31 > > An: Vetter, Michael > > Cc: ebxml-cppa-comment@lists.oasis-open.org; ebxml-cppa-negot > > Betreff: Re: [ebxml-cppa-comment] AW: AW: Re: Automated CPA > > Negotiation > > Wichtigkeit: Niedrig > > > > > > Michael, > > > > I have a further reply to your questions below. > > > > You asked: "I meant the composition of an NDD (section 11.3) > > from two NDDs. > > If both NDDs contain the element <PreferenceFunction> with > > the same XPATH > > expression, what should be the result in the combined NDD?" > > > > My previous reply on this point is true in general. For your > > specific > > example, the answer is a bit different. For this case, it > > appears that the > > prospective trading partners are in agreement on the particular > > element. Therefore for this element, there is nothing to > > negotiate and > > nothing is needed in the combined NDD that is sent in the initial > > offer. Instead, the offering party can place the two XPATH > > expressions > > directly in the CPA Template, with each referencing the > > appropriate partner. > > > > Regards, > > Marty > > > > At 02:11 AM 7/28/2003 -0700, Vetter, Michael wrote: > > >Marty, > > > > > >Thank you for your answers. > > >See my replies below. > > > > > >Regards > > > > > >Michael > > >_____________________________________________________________ > > __________ > > >_____ > > > > > > Dipl.-Inform. Michael Vetter > > > CC Electronic Business Integration > > > Fraunhofer IAO (Institut fuer Arbeitswirtschaft und > > Organisation) > > > mail: Nobelstrasse 12, D-70569 Stuttgart, Germany > > > phone: +49 (0) 711 970 2324 > > > fax: +49 (0) 711 970 5111 > > > email: Michael.Vetter@iao.fhg.de > > > www: www.ebi.iao.fraunhofer.de > > >_____________________________________________________________ > > __________ > > >_____ > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > > > > > >-Are the preference functions of both partners in a single > > > > matched NDD > > > > >that is part of the (counter-)offer with a CPA-template? > > > > > > > > MWS: There are some rules on order of preference when several > > > > alternatives are given in the NDD. See, for example, > > section 11.4. > > > > See also my reply below. > > > > > >I meant the composition of an NDD (section 11.3) from two > > NDDs. If both > > >NDDs contain the element <PreferenceFunction> with the same XPATH > > >expression, what should be the result in the combined NDD? > > Inserting both > > >functions with references to the corresponding partner could > > be one option > > >(this would require a change in the NDD.xsd). Another option > > is to exclude > > >the <PreferenceFunction> from the combined NDD and both > > parties have to > > >use their original NDD for the negotiation process too. > > > > > >In case of a conflict in the NDD composition it would be helpful to > > >express the conflict in the NDD too. Then the other party > > can be informed > > >about the problem and both can look for a solution. Alternatively a > > >similar format could be specified for this purpose (e.g. > > NCDD negotiation > > >conflict descriptor document). What do you think about that? > > > > > > > >-Are there elements for a total utility function and a minimum > > > > >total utility value in the NDD? This would give the negotiation > > > > algorithm a hint > > > > >to decide on several elements with preference functions. > > > > > > > > MWS: Version 1 of this specification will cover only the > > negotiation > > > > protocol (message exchanges and rules for working with the > > > > NDD) and not > > > > the negotiation algorithm. As mentioned in section 14 > > (Negotiation > > > > Algorithm), the negotiation algorithm, including entities such as > > > > utility functions, is out of scope for version 1. In > > version 1, the > > > > negotiation > > > > algorithm is viewed as a private strategy matter of each > > > > party. Admittedly, > > > > the specification would be much more powerful if it included > > > > negotiation > > > > strategy functions. However the sub-team's consensus was > > > > that it would be > > > > best to start with the functions that are in the draft and > > > > leave the much > > > > harder negotiation strategy problem for a later stage. I am > > > > hopeful that > > > > version 1 has enough functionality to be useful and might > > > > attract experts, > > > > such as yourself, on the higher level negotiation functions, > > > > who might wish > > > > to contribute to standardizing that level of negotiation. > > > > > >I understand that the negotiation algorithm is a private matter. > > >However > > >there needs to be a way to configure the algorithm with > > parameter values > > >for each NDD. Do you recommend to use non standard > > extensions of NDDs or > > >rather a different document for this purpose? > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: > > >ebxml-cppa-comment-unsubscribe@lists.oasis-open.org > > >For additional commands, e-mail: > > ebxml-cppa-comment-help@lists.oasis-open.org > > > > ************************************* > > Martin Sachs > > standards architect > > Cyclone Commerce > > msachs@cyclonecommerce.com > > > > > > ************************************* Martin Sachs standards architect Cyclone Commerce msachs@cyclonecommerce.com You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_ workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]