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

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: McClure Proposal and Web Site


John,

We should decide as a group, I think, but here are my initial
impressions:

Process: I think that each original purveyor of a scenario should be
allowed (and even encouraged) to tweak the scenario as we move through
the requirements setting process and learn more.  The act of
extracting requirements from a general user-based scenario can and
does shed more light on the scenario itself, and will sometimes
appropriately call for further honing of the envisioned scenario.

Substance: As to the specific content of what you propose, I think it
is very useful.  It demonstrates that we are all starting to talk to
rather than past one another.  One small semantic reaction: it is not
necessary to have a final conclusive block of content in order to have
an enforceable contract (though clearly that is advisable for many and
probably the majority of situations).  There are types of automated
transactions, verbal agreements and other conduct that in context will
be found to create a contract, and yet it is not legally necessary or
even appropriate to require that "display [is] immutable."  However,
having noted this, I do agree that there is a large class of contracts
for which the scenario you propose would be totally appropriate.  As
we continue through the requirements setting process, it is up to the
TC to decide which of the many scenarios submitted our specification
will support in the scope.

Web: Finally, I should note that we need to do a better job keeping
track of our data in the TC.  I think we should have links from our
web page to each scenario we are working with (there are several now,
more than two others) and we should include our minutes and other
content as we develop it.  OASIS has installed a new content
management system.  Is anybody out there interested in taking some of
the load off Dr. Leff and helping to create and update our web site?

Thanks,
 - Dan Greenwood

-----Original Message-----
From: John McClure [mailto:jmcclure@hypergrove.com]
Sent: Monday, April 28, 2003 2:57 PM
To: Legalxml-Econtracts
Subject: [legalxml-econtracts] eContracts Architecture
Importance: High

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]