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

[Martin Sachs <msachs@cyclonecommerce.com>]

Monica,

I agree with your comment.  The point of the simplification effort is 
precisely to reduce complexity by limiting functionality in the first version.

I will reply to Sacha's comments later.

Regards,
Marty


At 07:08 AM 10/23/2003 -0700, Monica J. Martin wrote:
>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
> >
> >
>mm1 Sacha, I think this brings up an interesting point about
>differentiating composition from negotiation; and and as you state
>continue to become more complex.  Marty, I think some of these arising
>challenges and complexities are indicators where we may wish to include
>our simplification effort.  It may in some ways limit functionality to
>start, but it may also lower the barrier to entry and use of the
>concepts, if simplified.
>
>Thanks.
>
> >The output of the CPA composition process is a new NDD_for-cpa-template
> >plus a new CPA template.
> >
> >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))?
> >
> >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.
> >
> >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.
> >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
> >
> >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.
> >
> >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).
> >
> >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.
> >
> >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...
> >
> >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
> >...
> >
> >Hope this makes some sense.
> >
> >Kind regards
> >
> >Sacha Schlegel
> >
> >
> >
> >
>
>
>
>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.

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