OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: AW: Re: Automated CPA Negotiation


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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]