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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[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]