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

[Martin Sachs <msachs@cyclonecommerce.com>]

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