[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 oneChannelId
Hi Marty Thanks for your reply. My comments also as SS: Kind regards. Sacha On Fri, 2003-10-24 at 11:34, Martin Sachs wrote: > 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 SS: OK. And both tasks have an important job. First to get to a CPA_template and then to finalise it. > > > >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. SS: OK. Thanks. > > >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. SS: OK. True a party cannot modify another parites CPP, at a registry for example. What I mean is rather that a party A might modify the other parties B PartyInfo element, or its children elements in the CPA template. But not the real CPP. And, as we discussed in another email, party B then could, if they think it is important, change their CPP at the registry. But party A has to send these changes of the PartyInfo of Party B of the CPA template to party B along the first intial offer in the NegotiationContent element. Then it is up to Party B to accept, reject or make a counter offer. > > >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 SS: OK. > > >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. SS: So you are thinking that the CPA negotiation processes at both sides have to check the CPA template. I think the first initial offer will need a thorough check at the receiving side. A check of the CPA template, the NDD and the Negotiation Conent. > However putting information in > the NDD that indicates where t conflicts exist might enable the > negotiation to converge more rapidly. SS: OK. I think I havent played a CPA negotiation through in my head yet. Question: Only what is in the NDD is negotiatable, right (OK and enumerations in the CPA template)? This question lead me to think that the CPA composition process is very important as it defines what is negotiatable and what is isnt, in the form of an NDD. Even if the CPA negotiation discovers a problem they might not be able to negotiate over it because it is not listed in the NDD. A possible restart of the CPA Negotiation at that point, with the improved CPA template and a newly created NDD might help to overcome that problem. > > >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. SS: OK. Again both sides need some intelligence how to handle the CPA template, eg when to remove what elements for example. Its going to be interesting how the negotiation takes place with different algorithms doing the negotiation... > > >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". SS: I mean the ChannelIds of the ThisPartyActionBinding as more of that element indicate that a party supports more than one DeliveryChannel. Removing a ChannelId is easy but that means it also has to be checked if it can remove the DeliveryChannel the ChannelId is referencing to. In that check it has to be made sure that no other ChannelId from other ThisPartyActionBinding elements are referencing that DeliveryChannel. If no others reference it, it can remove the DeliveryChannel if not it cannot remove the DeliveryChannel but only the ChannelId in ThisPartyActionBinding. > > >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". SS: Sorry but I cannot find a "Channel" element in the cppa-v_2.xsd schema. Do you mean "DeliveryChannel"? > 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. SS: If there is just one combination of channels (or DeliveryChannel's), then there would be no other conflicting channels ... right? > 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. SS: Yes I agree. > \removed from later email > 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 \removed from later email > > >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. SS: Yes I also agree. > > >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. SS: I think the first inital offer message will be of imporantce as it has a) the CPA template, b) the NDD, and c) possilbe values in the NegotiationContent. If party B creates the CPA template and the NDD_for_the_CPA_template and party A has not published their NDD for their CPP, then if it is very likely that party A does not accept the intial offer, or not even the NDD because its NDD was not considered at all and thus elements of its NDD might not be in the NDD_for_the_CPA_template and thus not negotiatable at all. My thinking is based on the rule that during the CPA negotiation only the elements/attributes listed in the NDD are negotiatable. Please correct me if this assumption is wrong. > > >... > > > >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 > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. > > > > > !DSPAM:3f98a062142725822684102! -- ------------------------------------------------ Sacha Schlegel ------------------------------------------------ 4 Warwick Str, 6102 St. James, Perth, Australia sacha@schlegel.li www.schlegel.li public key: www.schlegel.li/sacha.gpg ------------------------------------------------
This is a digitally signed message part
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]