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