eContracts Architecture

["John McClure" <jmcclure@hypergrove.com>]

I have been thinking lately how to modify the DC Requirements statement into one
that the group would think more useful, and not duplicative of the other two
scenarios. Here is my suggestion, offered in the spirit of moving the overall
conversation forward. I suggest that we formally recognize at this point in the
requirements process that our architecture envisions 3 separate documents that
can be excahnged between parties to the contract. My expectation is that, while
the details of Scenario 2 are being worked out, development of Scenarios 1 & 3
can continue moving forward at their own, quick, pace.

1. Scenario: CONTRACT NEGOTIATION

This scenario represents the requirements for a schema for a 'negotiating
document' that is exchanged between the parties to a contract being negotiated.
We're made great progess in this regard, covering contract values, agreed-to
clauses, clause authors and so on. This schema would allow an XSL-T stylesheet
to be applied against itself to yield an image of the contract being negotiated,
if so desired.

2. Scenario: CONTRACT EXCHANGE

This scenario represents the requirements for a schema for 'the contract' as
offered for acceptance. This is the document that would be filed with a court if
ever legally contested. This schema would not allow any transformation to be
applied to the contents of 'a contract' - Its contents and display would be
immutable.

3. Scenario: CONTRACT MANAGEMENT

This scenario represents the requirements for a schema for a 'contract
management document' that can be exchanged between parties to the contract. This
document contains information about the events that have occurred, or failed to
occur, to-date under the contract, and those events that are expected to occur
under the contract. This document further would cite all amendments that were
agreed to by the parties to the contract since its acceptance. This document
could identify the current participants assigned to "roles" defined within the
contract. For automated contracting scenarios, this document could list the
"micro-agreements" such as JMessing and others seem to want (basically, with the
view that the formal TPA covering the micro-agreements would be the actual
'contract')

Comments?
John McClure