RE: more on collaborations, contracts and 2-27 minutes

["Welsh, David" <David.Welsh@nordstrom.com>]

Question ?

It can occur today that a special part of the b-2-b agreement made w.r.t. exchanging 'messages' calls for the sender to ensure that 'messages' sent are 'tagged and counted sequentially'; so the receiver can do 'things' / maybe legal things like ignore a well formed document if it's out of conversational sequence.

I'm sorry to bother folks, but I was trying to find this concept back in the ebXML work and I was wondering if someone could point me to the right ebXML source on the subject ?

I can understand that at a lower level TRP service, there's something dealing with 'message counting' but I'm not aware that something like this info finds it's way up the stack so the business app's can also do their counting; which does sound like redundant but it is the way of the world and as such it's not going to stop.

Thanks

Dave

 

-----Original Message-----
From: James Bryce Clark [mailto:jbc@lawyer.com]
Sent: Monday, March 05, 2001 8:13 AM
To: ebxml-bp@lists.ebxml.org
Cc: Karsten.Riemer@east.sun.com; linkage@interaccess.com; jbc@lawyer.com; sharma@netfish.com; marcia.mclure@mmiec.com; jdc-icot@lcc.net; mccarth4@pilot.msu.edu; David.Welsh@nordstrom.com
Subject: more on collaborations, contracts and 2-27 minutes

With all the talk of contracts and REA I think we are getting a bad case of concept creep.  There is too much talk about legal contracts in the BPSS and not enough clarity. The following distinct kinds of behavior may lead to contract formation.  We should support all of them, now or later.

a.      A single request/response pair.  Each is composed of one, and only one, pattern (as the term is used in N90 section 4.4 or BP22 v0.90 lines 526-531).  One Business Transaction, necessarily enclosed in one Binary Collaboration.  This can itself be a legal contract, e.g., order and acceptance.  Incidentally, it MAY be about REA economic events and if so, I think WILL possess valid REA duality. 

b.      A series of independent request/response pairs in a single Binary Collaboration.   No transition states or conditionality.   E.g., the parties fire a couple of tentative orders and responses across the wire, followed by a definitive order and acceptance.  Here, the "contract" is the definitive final pair.

c.      A sequence of dependent request/response pairs in a single Binary Collaboration.   By entering into the collaboration pattern, the parties agree to the stated "precondition", and other collaboration choreography relationships.  (E.g., we agree to do X, Y and Z, in a certain order, and success of X and Y are preconditions for Z.)   The "contract" arises wholly from the simple preconditions relationships.  Incidentally, this generally supports the exchange of REA economic events, but not exchanges of promises (which I think REA would call economic commitments). 

d.      Pattern (c), but with more than two parties entering into a Collaboration in which

·       multiple Binary Collaborations are nested;

·       conditionality relationships may extend across Binary Collaboration boundaries, i.e., address what other folks are doing elsewhere in the composite collaboration;  and
·       all parties have an opportunity to verify each others' identity and subscription to the composite collaboration.

e.      More robust use of the "beginsWhen" and other conditionality tags in N90 (3.3.1.1).  Depending on how complicated you get with Notification (N90 4.4) and other patterns, this might adequately logically process exchanges of promises, i.e., REA economic commitments and fully modeled "contracts".  This could be a binary (as in pattern (c)) or multiparty (as in pattern (d)) process. 

f.      Any of the foregoing, but constrained by an ex-ebXML legal contract under which the parties have agreed (outside of a collaboration's internal choreography) to follow a common business logic in performing that specific collaboration.  That agreement, which is itself a contract, may or may not be automated.  E.g., an ebXML-driven set of orders and responses might be exchanged, but explicitly subject to the terms of a written general term agreement, master purchase agreement or the like.  

In order to support these, we need the following things that I don't think we have.  This disagrees with some substantial parts of the 2-27-01 draft metamodel minutes Karsten supplied.

i.      A textual blurb explaining that case (a) can be a contract, so long as there is a CPA that gives you some rudiments of legal enforceability.  Action item:  I am going to provide something here that I don't think will be terribly surprising or controversial. 

ii.     A pattern that demonstrates (b), and a way to distinguish enforceable messages from proposals, live from duds, etc.  I can think of two ways to do this.  One (which I prefer) is a tagged value for requests and responses, e.g. "IsBinding".  The other is a separate transaction type -- e.g., use of the pattern pair called "Commercial Transaction", not "Request Response".  I think the latter would take more work.  Either way we have to tell people that there is a logical switch, and how to turn it on or off.  I do not include use of XML-DSIG as an option, because we have reserved it for optional use as an assurance of message integrity (in the CPA spec) and sender identity (in the BP spec nonrepudiation tags.)   Action item:  I want to add an "IsBinding" tag or something like it.  

iii.    In order to permit (c), we need to support at least the "precondition" parameter.  Seems to me that the current BPSS transition and guard mechanism does that, but it is not explained in a very user friendly way.    Action item:  Assuming I'm right that this is logically achievable, I would like to tweak that language a bit.  Also, Karsten's March 1 message suggests gutting "precondition" for now.  I think that's not a good idea. 

iv.     In order to permit (c), we need to support at least the "precondition" parameter.  Seems to me that the current BPSS transition and guard mechanism does that, but it is not explained in a very user friendly way.    Action item:  Assuming I'm right that this is logically achievable, I would like to tweak that language a bit.  Also, Karsten's March 1 message suggests gutting "precondition" for now.  I think that's not a good idea. 

v.      In order to permit (c), we need to support the "every party verifies who else is at the table step" I mentioned above.  Action item:  We'd need to supply a pattern to illustrate this.

vi.     In order to permit (d), composite collaborations, we also would need to constrain the selection of dependency references and endstate descriptions so that there is a unified vocabulary for each composite collaboration -- that is, unique hooks for each of the Binary Collaboration outcomes.   Action item:  I think this would require some additions to the wellformedness rules.

vii.    We have agreed that (e) is out of scope for 1.0.  However, in order to leave it within reach for the future, I think we need not to corrupt the full set of tagged values in N90 2.3.11 and 3.3 -- "beginsWhen" and all that.  There was a suggestion that in San Jose the BPE subteam decided to do otherwise.  I wasn't there;  I guess I need that clarified.   Action item:  If we need more tagged values, we should explicitly add to the N90 ones, or exclude them for now from a suggested pattern, but not modify them. 

       viii.    In order to permit (f), we need to provide a new parameter along the lines of Karsten's suggested "isGovernedBy".  Action item:  We should discuss how this works, and how it interacts with CPA formation.

Jamie