AW: [ebxml-cppa-comment] AW: AW: Re: Automated CPA Negotiation

["Vetter, Michael" <Michael.Vetter@iao.fhg.de>]

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 
> 
> 
>