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] | [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">&sup; 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