[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Clarification - FORK and BusinessTransaction
Dale Moberg wrote: > <>It would be technically possible, perhaps, to have a Notification > followed by a Notification. However, the semantic state primitives of > BPSS have been the BTAs (each related to a BT). I have not sought to > overturn that form of representation, because that is what supposedly > represented the unit of work of UNCITRAL, and I chose to make those > choices work within a notation for process, regarded as a state > transition graph over the chosen states. Your query then, should > probably be redirected to UNCITRAL, and why they > have chosen a RequestResponse, when they could have had two > Notifications. I assume they would say they had different commitments > reflected, and it was not appropriate to analyze in that fashion. I am > sure you can tell us in some detail how those commitments differ. I dont think UNCITRAL has anything do with BT's structure. They dont even know we exits :) From a legal point of view it doesnt matter what BPSS calls its logical grouping of data message exchange specifications. What matters are the actual data messages that are prescribed to be exchanged. One BT with 2 data messages with transactional roles Request/Responce or two BT's with a Notifications on each may be the same. What is important which *Function* each message has. A data message with role "Request" in a RequestResponse BT may have the same Function as a data message with role "Notification" in a Notification BT. You can create an all data message exchanges that is related to Contract formation into a new single OfferAcceptance BT or you can spread all them in a BinaryCollavoration. This is why I dont think we need a Composite, Nested, Embedded BusinessTransaction structure and the onInitiation flag. BTW I converging to the view that the AcceptanceAcknlowledgement should be a data message and not a Signal This will simplify the problem with a POConfirm in Responces message. Just one data message that has the function of Contract conclusions So the POConfirm dokument together with the act of sending it has the Function of Contract acceptance. /Anders -- ///////////////////////////////////// / Business Collaboration Toolsmiths / / website: <www.toolsmiths.se> / / email: <anderst@toolsmiths.se> / / phone: +46 8 562 262 30 / / mobile: +46 70 546 66 03 / /////////////////////////////////////
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]