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

[Martin Sachs <msachs@cyclonecommerce.com>]

Michael,

Thank you very much for your questions.  I have a few answers below but you 
are raising questions that we have not thought about. I am cross-posting 
this to the ebxml-cppa-negotiation list to ensure that the full 
subcommittee sees your comments. I am documenting your comments with other 
matters that need discussion and decisions.

I look forward to your eventually joining OASIS and participating more fully.

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.

MWS:  For a set of choices, the specification advises the party making the 
initial offer to include in the  initial-offer NDD only those choices that 
are agreeable to both parties. We have a lot more work to do on preference 
functions. Your suggestion is a good one.  Since we are working on a draft 
of version 1, modifying or extending NDD.xsd at this time is fully acceptable.

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

MWS:  At this time, the team is recommending that if the party making the 
initial offer recognizes an apparently unreconcilable conflict, the two 
parties should discuss outband (e.g. telephone) before one makes an initial 
offer. I am in the process of making changes in section 11.3 to clarify the 
rules for use of both NDDs by a party who is preparing an initial offer. 
Your suggestion is interesting and I hope that it will generate some 
discussion within the subcommittee.

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

MWS:  I agree with you on the need to configure the algorithm.  Our present 
plan is to defer this and related questions to version 2.  I expect that we 
could extend the NDD definition to include well-understood parameters, such 
as those that are common to most or all algorithms, and use a 
well-understood XML extensibility method to allow a pair of parties to add 
additional parameters.


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