[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa-negot] Re: BPSS Start element
John, I agree. We need the flexibility to control whether a particular binary collaboration can be entered directly or only from a higher level binary collaboration. I think that my suggestion (previous posting) to assign a specific meaning to absense of the Start element does that. Another way is to complete the definition of preCondition so that its value can be interpreted by a BSI or deployment tool. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "John Yunker" <john. To: Martin W Sachs/Watson/IBM@IBMUS yunker@bleuciel. cc: <ebtwg-bps@lists.ebtwg.org>, <ebxml-cppa-negot@lists.oasis-open.org>, org> "Jean-Jacques Dubray" <jjd@eigner.com> Subject: Re: BPSS Start element 08/09/2002 03:18 PM <MWS> I believe that if I want the nested collaboration to be treated as a state machine encapsulated within the outer collaboration, I should state my intention by omitting a Start element from the nested collaboration. The transition element in the outer collaboration will take me to the encapsulated nested collaboration at the appropriate place in the choreography without needing a start element in the nested collaboration. I don't find words in the BPSS spec that tell me to do that, </MWS> Marty, yes you could do that, however I would reserve the right to place conditions on both the transition and the nested start state. Since I am trying to reuse standard collaborations I will want to normalize the conditions between the transition (those conditions dependent on the context of both collaborations) and the nested start state (those conditions applicable to all uses of the nested collaboration). For instance, I may have a transition from a quote to an order (order encapsulated in quote) where in to start the nested transaction I need both an approved quote and an authorized customer. Note that the approved quote condition is important only when the order and quote are used together (place on transition), but the authorized customer is important for all uses of the nested transaction (place on nested start state). As we build standard libraries of business transactions, this ability to normalize will be critical. Thanks!!! John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC