[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [legalxml-econtracts] Thinking about information models
Dear Folks, Your last postings do really make a lot of sense. I would however like to submit a few additional points for consideration around the models put forward by Dave (and with both contract-generation wizards and automatic negotiation in mind): a) I agree that the "physical model" should be left to stylesheets, provided that the pagination does not have an impact on the legal effect of the overall contract -thus falling within the "structural model"- (and I can't think of any real situation in English or Spanish law where that would happen, unless specifications or descriptions are incorporated by reference -to a schedule or annex-, in which case I would rather keep them out of the "main" contract and treat them as "annexed" documents that could be subject to their own environment-specific description language). b) In the line of what Jamie has said, both the "structural model" and the "obligation model" do appear to me as mere steps along the way towards the absolute abstraction of contract terms that leads to the "parametised model". Is a half-way stop then necessary? Could it coexist with a "parametised model"? I think yes, but I wonder where, along that way, should we stop. Keeping the "obligation model" aside for the time being, I think a "structural model" is necessary because most real-life contracts are negotiated between human-beings and a model should be in charge of tagging the same words and sentences the signatories are supposed to be able to negotiate and understand. I would fit John's proposal in this sort of model, and I believe a division in Sections, Clauses, and Paragraphs would help identify different parts of a legal contract in, for instance, a contract wizard application. On the other hand, the model above might prove worthless when it comes to contract automation, unless clauses and subclauses can be made truly unique and their values be easily pulled out of the paragraphs and clause containers, which leads us to coexistence with a "parametised model". Explaining myself: I believe all contracts usually come down to four groups of clauses (which could become five, or six, if we did a thorough analysis of all known contracts): - "contract mechanics*": where the obligations of the parties are set forth in a way that is unique to a type of contract that is recognised and enforced by a legal system under a given legal figure, whatever its variations (and a contract often incorporates the "mechanics" of multiple simultaneous legal figures) -eg: paying the price in a sale of goods-. - "exception handling" (the legal try/catch): aimed at keeping the rest of the contract alive by overcoming certain events that would otherwise constitute a breach, including interests for a delay in payment, indemnities, etc. - limitations of liability: providing certain shields and rules for those situations where breach has already taken place. - choice of law and jurisdiction Taking the example of a contract for the development of a software application, a single contract could merge the "contract mechanics" of five different legal "figures" common to multiple legal systems: -"supply of services" -"confidentiality agreement" -"exclusive and non-transferable licence (IP rights)" -"training" -"maintenance" Drilling-down on the "supply of services" "sub-agreement", it could contain certain words indicating the obligation of the supplier to provide such services "with reasonable skill and care" (which may be implied in certain jurisdictions). Such words could become part of the contract in many different ways: -As a stand-alone clause, with its own subclauses determining the extension of such obligation -Grouped together, as a subclause, with the clause that defines the "Obligations of the Supplier" -Grouped together, as a subclause, with non-"contract mechanics" clauses (eg, a "limitation of liability" subclause) to name just a few. In fact, my point is, the arrangement of clauses may not have an impact on the legal effect of the contract's wording. In the end, the logical structure remains the same: A bunch of scattered terms that could be associated according to multiple criteria. Which leads me to say that the real strength of a classification in Sections, Clauses, and Paragraphs would lie on its ability to describe the true nature of the clauses being marked, rather than its actual, human-readable arrangement, in the line of something like this: <section name="jurisdiction" type="law and jurisdiction"> <clause id="jurisdiction" value="sweden">The parties submit to the exclusive jurisdiction of...</clause> </section> <section type="mechanics"> <agreement scope="intellectual property"> <clause id="copyright" value="licenceUseNonTransferable">⊃ gives &cli; a non-exclusive...</clause> </agreement> <agreement scope="confidentiality"> <clause>Each party agrees and undertakes...</clause> </agreement> </section> (each of those sub-agreements could be an object in itself, with its own figure-specific elements) Of course, the identification of all possible unique clauses and their own child elements/attributes across multiple jurisdictions can prove a daunting task. Anyway, looking forward to reading more alternatives. Best regards, Sergio * I'm borrowing this term from Professor Reed, at the Centre for Commercial Law Studies in London. Sergio Maldonado Elvira sergio@smaldonado.com http://www.smaldonado.com -----Original Message----- From: James Bryce Clark [mailto:jbc@lawyer.com] Sent: Wednesday, January 29, 2003 6:37 PM To: legalxml-econtracts@lists.oasis-open.org Subject: Re: [legalxml-econtracts] Thinking about information models Hello all. Dave's comment points up a fundamental issue in our space. As Rolly said, theoretically one can dismiss the physical model as a trivial problem and rely on transforms. In fact you can view any of the layers Dave describes (below) as a trivial production from another one. In theory. But in real life transforms are nontrivial. In software, roundtrip transforms today -- XMI and the like, and managed code generators generally -- are not always as reliable as we might hope. As practicing lawyers, we see analogous problems daily: -- multi-language written contracts with which-one-is-definitive issues; -- B2B software that executes on business object models that prove woefully nonisomorphic to the modeled reality; -- content taxonomies that by reason of logical flaws overlook or mischaracterize important data; and so on. In advising clients I insist on knowing which representation of a contract is the definitive instantiation. Always. None of this "heh, the OO representation is just as good", unless the object model is unambiguous and is the designated tiebreaker artifact -- because I get paid to ship certainty (or at least an expert assessment of its availability). So I am chary about simultaneous parallel representations without a clear provision for resolving inter-schema conflicts. I am enthusiastic about Dave's view, but for that reason think it needs to be approached with caution. Best regards Jamie At 12:23 AM 1/28/2003 -0800, Dave Marvit wrote: It seems to me that the lens used to look at a contract determines which information models are most significant. * * * 1. A physical model document * * * 2. A structural model document * * *.. 3. An obligation model document * * * in terms of commitments * * * 4. A parameterized model * * * * * * ~ James Bryce Clark ~ 1 310 293 6739 jbc@lawyer.com ~ Chair, US ABA Business Law E-Commerce Subcommittee ~ This message is not legal advice or a binding signature. Feel free to ask me why.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC