Re: [legalxml-econtracts] Scenario: Contract Generation Systems

[jmessing <jmessing@law-on-line.com>]

I think this is a very noteworthy contribution.

I think with regard to the contributions to eContracts made to date we should be following the OASIS rule requiring a statement from the contributor that there is not any known intellectual property claimed in the contribution, as by copyright or otherwise. This is the rule that is followed in non-LegalXML TC's and we should begin to conform our practices.

Best regards.

---------- Original Message ----------------------------------
From: Sergio Maldonado <sergio@smaldonado.com>
Date:  Wed, 26 Feb 2003 18:21:01 +0000

>OASIS LEGALXML ECONTRACTS TC - SCENARIOOASIS LegalXML eContracts TC
>Requirements Process
>Scenario -  Contract Generation Systems
>      Name  Contract Generation Systems
>      Principal Stakeholders Legal Professionals in Private practice
>      Scenario Owner  Sergio Maldonado, sergio@smaldonado.com
>      Draft Number 1
>      Draft Date February  23, 2003
>      Contributors
>
>Introduction
> Although in legal terms a "contract" can be defined as the final result of
>an exchange of promises (for the breach of which the law gives a remedy or
>the performance of which the law recognizes a duty), the same term is often
>used to refer to a written draft produced by either one of the parties along
>the way with the intention of being agreed upon in the near future in
>accordance to a certain legal figure as such figure is recognized in a given
>legal system. In effect: A pre-assembled compilation of certain terms that,
>according to the applicable legal system, would frame the resulting
>relationship within the limits of a specific legal figure.
>
>A "legal figure", as defined above, could therefore be a "sale of goods",
>"supply of services", "copyright licence", "real estate tenancy",
>"confidentiality agreement"... etc, its scope, obligations and limits
>determined by the applicable statutory and case law in the legal system
>where such figure arises.
>
>Scenario Statement
>Virtually everybody needs to make use of a "pre-assembled" contract (a
>"draft"), as defined above, at some point in time. Such pre-assembled
>contracts enable everyone to enter into more or less sophisticated legal
>relationships with relative simplicity. As lawyers, we also make use of
>pre-assembled contracts, as they avoid us having to start from scratch every
>single time.
>
>However, pre-assembled contracts pose important limitations:
>
>a) Non-lawyers are not able to ascertain the flexibility of the terms: Some
>of them must remain as they appear on a sample draft for the contract to
>have the desired effect (namely, that the parties end up creating the
>envisaged "legal figure"), while some others may be subject to a choice of
>pre-defined options (therefore allowing certain negotiation) and some others
>remain absolutely flexible.
>
>b) Lawyers may find it a daunting task to update all relevant terms in their
>pre-assembled contracts, plus all those in the sub-agreements that such
>pre-assembled contracts may have emerged from every time a new court
>decision or statute directly interferes with them.
>
>c) Lawyers and non-laywers alike will normally find it extremely hard to
>produce a similar contract (or obtain an analog legal figure) in a separate
>legal jurisdiction where the flexibility of the terms for such legal figure
>might vary greatly.
>
>Computer-based systems have arisen in the past allowing lawyers and
>businesses to obtain "customized" pre-assembled contracts and tackling the
>aforementioned limitations with more or less success, but mostly limited to
>a specific area of law (and very limited range of legal figures) and a
>particular legal system.
>
> The arrival of XML may now provide the necessary tools towards creating
>fully-operating, computer-based "contract-generation" systems (or "wizards")
>with much greater ease and interoperability.
>
>Contract Generation Systems and XML
>Contract Generation Systems (CGS) should be able to:
>
>1. Identify particular sub-agreements within a given draft (each
>sub-agreement could represent a "legal figure")
>
>2. Group clauses by reason of the sub-agreement they belong to (eg. a
>particular "quantity" may belong to a "sale" in a contract that combines a
>sale of goods and a supply of services)
>
>3. Capture the different options available to the formulation of every
>single clause (and thus, a "force majeure" clause will by nature be much
>less flexible/negotiable than a "choice of jurisdiction" one)
>
>4. Pre-assemble a draft from a group of particular sub-agreements
>
>5. Deliver the final result in a number of different formats (PDF, Word,
>HTML...)
>
>
>
>For a start, I have provided an example (unfortunately still in Spanish,
>although generating a contract in English if required) here:
>
>http://www.smaldonado.com/marcos/services/cw_es1.cfm
>
>In any case, the example is based on a wizard (a series of forms) that
>gathers from the parties:
>
>a) the parties' details
>
>b) the parties' choice of legal system (which will determine the nature of
>the contract as well as its language)
>
>c) the parties' input for "open" clauses (eg. "price")
>
>d) the parties' choice amongst a set of mutually exclusive options in
>"semi-open/semi-negotiable" clauses (eg. intellectual property rights in the
>resulting works)
>
>Such details are eventually used against a particular document/contract
>draft that becomes a datasource to the final "customized" draft where
>parties' data are treated as variables and clauses are automatically
>numbered. The process can prove extremely painful without the assistance of
>XML, as it requires a great amount of redundant conditional statements and
>the manipulation of multiple variables. Additionally, proprietary
>"translators" and tough programming are required for the final result to be
>output in multiple formats (in the example provided, RTF and HTML).
>
>XML would effectively do away with all this.
>
>Requirements
>
>XML  should enable the use of particular sub-agreements or complete drafts
>as datasources, themselves being self-descriptive of:
>
>a) An applicable legal system according to which the resulting legal figure
>will arise (eg "California Law" or "Law of England and Wales")
>
>b) The legal figure/figures that the parties intend to create (eg
>"Confidentiality agreement" or "Leasing")
>
>c) The particular clauses (so that each clause can be easily tracked without
>need for scanning the actual content of the element -eg "Choice of
>Jurisdiction")
>
>Besides that, XML enables the automatic substitution of the parties' names
>and details through the use of entities.
>
>Additionally, XSLT allows for multiple different outputs of the same XML
>document.
>
>As a consequence it is submitted as a suggestion that an eventual eContracts
>Schema counts with:
>
>- A main element/attribute describing the legal system which inspires the
>contract (itself miles away from the applicable law or jurisdiction chosen
>by the parties in the event of a dispute). A combination of ISO country
>codes and region/state/province codes would also provide a predefined range
>of limited values that would greatly enhance automation (eg. UKSC for
>Scotland).
>
>- A main element/s describing the "legal figure"/range of "legal figures"
>that the contract will create once it becomes binding to the parties.
>Although a shortlist of them is hardly viable, a naming convention could be
>agreed so that parsers can be easily built for a smaller range of familiar
>figures in each particular discipline (eg: SG for sale of goods)
>
>- An identifiable Clause element nested within the particular legal figure
>it belongs to (so that, for instance, in a Software Development contract
>certain clauses can be associated to the Confidentiality sub-agreement and
>certain others to the IP licensing sub-agreement)
>
>- Various entities representing, mainly, the parties.
>
>
>