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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-negot message

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


Subject: Re: [ebxml-cppa-negot] How to get from multiple ChannelId's to one ChannelId


Hi, Sacha

You are raising excellent points.  I have some replies below (MWS:).

Regards,
Marty

At 12:06 PM 10/23/2003 +0800, Sacha Schlegel wrote:
>Hi everyone
>
> From my understanding there are two necessary processes how to get from
>two CPP's to a final CPA.
>
>1. process: CPA composition
>2. process: CPA negotiation
>
>The output of the CPA composition process is a new NDD_for-cpa-template
>plus a new CPA template.

MWS:  Correct


>Question is: how to get from multiple ChannelId's to one ChannelId.
>
>What is the difference between enumerations laid out in the CPP instance
>Document (eg certificates) and enumerations laid out in the cppa schema
>itself (from The Automated Negotiation of CPA (ANCPA) Spec in 10.1
>(Enumerations))?


MWS:  An enumeration laid out in the CPPA schema is one that is formally 
defined with the XML Schema enumeration element.  An enumeration laid out 
in the CPP instance document is one which consists of a repetition of the 
same element (MaxOccurs greater than 1) where that element is defined just 
as a single element in the schema.  The Certificate element is an example 
of an enumeration laid out in the CPP instance document.

>I think the example of multiple ChannelId's in ThisPartyActionBinding
>goes into the cpp instance docuemnt enumeration problem...
>
>Assuming that the party who runs the CPA composition does not modify the
>other parties CPP and each CPP has multiple ChannelId's per CPP.

MWS: A party never modifies the other party's CPP. That party might not 
even have write access to the other party's CPP. Constructing the CPA 
template for the initial offer is all that is needed.

>Example:
>
><CPP id=1>
>   ...
>  <ThisPartyActionBinding>
>    ...
>    <ChannelID id=1>x</ChannelId>
>    <ChannelID id=2>y</ChannelId>
>    <ChannelID id=3>z</ChannelId>
>  <ThisPartyActionBinding>
>   ..
></CPP>
>
>
><CPP id=2>
>   ...
>  <ThisPartyActionBinding>
>    ...
>    <ChannelID id=5>a</ChannelId>
>    <ChannelID id=6>b</ChannelId>
>    <ChannelID id=7>c</ChannelId>
>  <ThisPartyActionBinding>
>   ..
></CPP>
>
>In this example there are 3 ChannelIds per ThisPartyActionBinding in
>each CPP
>
>The CPA composition would have to check all combinations (3x3 = 9) and,
>from my understanding, list conflicts as negotiatable items in the NDD.

MWS:  Correct

>There must be a way to indicate for which combination a conflict exists:
>
>combination-x-a: conflict in transport protocol (via XPath expression to
>transport protocol)
>combination-x-b: conflict in transport protocol version

MWS:  We might need an addition to the NDD to indicate these conflicts. 
Alternatively, it may sufficient to let the offer anc counter offer process 
deal with this as it discovers conflicts. However putting information in 
the NDD that indicates where t conflicts exist  might enable the 
negotiation to converge more rapidly.

>What I want to say is that once the CPA negotiation chooses
>combination-y-b as the one which will go into the CPA (however this is
>done) all conflicts of  the other combinations can be removed.

MWS:  I agree. The conflicting combinations MUST be removed from the CPA 
after the agreed combination is chosen.

>The more I think, the more problems I discover (eg in connection with
>BusinessTransactionCharacteristics) and probably should reread the ANCPA
>spec.
>
>It might be easier if the CPA composition tool leaves all ChannelId's in
>the CPA template (even if its basically a not ready CPA yet).

MWS:  I think that this should work. The negotiation  process would then 
remove those that cannot be used. By the way, I assume that when you say 
"ChannelIds", you really mean "Channels".

>An argument against could be that, in the case of the ChannelId example,
>the CPA composition tool might remove all ChannelIds and use (one or
>two???) Reference  elements in the NDD with a choice for CPP with id=1
>of x,y, or z and one Reference element in the NDD with a choice for CPP
>with id=2 of a,b, or c. This might be valid as the value of the
>ChannelId element _references_ another element.

MWS:  Again, I assume that you really mean "Channel", not "ChannelId". If 
there is just one combination of channels that works, the party 
constructing the CPA template should be able to assume that both parties 
would agree on this combination. Therefore, it is appropriate to remove 
conflicting combinations.  However, if more than one combination works, all 
those channels must be left in the CPA template and referenced by the NDD 
so that the final choice can be made during negotiation.


MWS:  If I understand you correctly, this does not work because we must 
assume that when there are multiple channels, those channels differ 
significantly.  We are not just negotiating what channel ID to use; we are 
negotiating the choice among channels with different characteristics. Thus 
we have to keep the channels in the NDD and put the appropriate references 
in the NDD.  I do agree that the NDD could just refer to channel IDs 
although that would require a new construct in the NDD instead of 
references to the individual channel elements.

>If the multiple elements on the other hand have children then, of
>course, it cannot be removed as all information would get lost, unless,
>all elements with their children will go into the NDD and the Reference
>element has elements with children as options. The Reference element in
>the NDD might have to be checked again...

MWS:  This is another reason why one can't remove some of the 
channels.  However if the NDD references each Channel element, it is 
unnecessary for the NDD to reference child elements unless the child 
elements are individually negotiable.

>Sometimes I think the content of the NDD has to be negotiate first (or
>agreed upon) and then negotiated over the elements described in the NDD

MWS: We certainly want to avoid the complexity of two levels of negotiation 
(NDD and CPA) and I don't believe that it is necessary.  The NDD tells what 
is negotiable and we use that information to negotiate over the CPA 
template. You may be referring to dealing with irreconcilable conflicts 
when you talk about negotiating the content of the NDD.  If that's what you 
mean, the consensus for the first version of the specification has been 
that getting around irreconcilable conflicts is to done "outband", i.e. by 
phone or email.

>...
>
>Hope this makes some sense.
>
>Kind regards
>
>Sacha Schlegel
>
>
>--
>------------------------------------------------
>Sacha                                   Schlegel
>------------------------------------------------
>4 Warwick Str, 6102 St. James, Perth,  Australia
>sacha@schlegel.li                www.schlegel.li
>public key:            www.schlegel.li/sacha.gpg
>------------------------------------------------

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com 




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