- What is a clause model?
A clause model is a description of the structure represented by the paragraphs of
text found in the body of a contract.
Those paragraphs have natural parent-, child-, sibling or
other relationships to each other, which a clause model ought to reflect. These
relationships are traditionally reflected in the clause numbering and layout (indentation) on
the page.
Our clause model is expressed in an XML schema language, so XML aware tools can be
used to manipulate contracts marked up in accordance with it.
- Why is a standardised clause model important?
You need a clause model if you are going to use XML technologies to draft and edit
contracts, which is something people currently mostly use non-XML aware word processors to do.
A clause model is necessary if XML technologies are to deliver what people already do
today with other tools.
A standardised clause model is desirable to realise the vision of people using a variety
of XML tools provided by different vendors to draft, edit and otherwise work with contracts
in XML. It is essential if people are to be able to work with one another's contracts,
without needing to convert them first for use with a different tool set.
"Legal" markup will build on the structure provided by our standard clause model.
- What are the goals of your clause model?
There are several:
- To be able to represent the clauses found in the vast majority of written contracts
- To be no more complex than is necessary to adequately represent that structure
- To be easy for people to understand
- When used in conjunction with appropriate stylesheet, to enable the clauses
to be rendered in a familiar human readable form, numbered as one might expect
- What does the clause model look like?
The levels in the hierarchy are named as follows:
(Open question: should we use abbreviations like "Para" and "SubPara" instead?)
A DTD for the current draft of the clause model will be found on the mailing list (not yet though).
The intent is that the authoritative copy will eventually be a W3C Schema, but for now,
we're using a DTD.
We haven't worked out how to model the bits of a contract that typically come before or
after the clauses, that is, the part which identifies the parties, the background to the
transaction, or where the parties sign (often called the execution blocks), but we'll do that
in due course.
- I don't see 'clause' anywhere in the clause model?
That's correct. Lawyers use the word 'clause' and words like 'sub-clause' to refer
to various different things. To avoid this confusion, we have abstained from using <Clause> entirely.
- What does it mean to me, a contract author?
If means that if you are using a word processor or XML editor with a reveal-codes feature which
allows you to see the XML element name tags which surround your paragraphs of text, you
will see tags for <Article>, <Section>, <Paragraph> <SubParagraph> etc.
- Why/how did you choose 'Article'?
From a technical perspective, the element names are just labels, which software
can manipulate. We could
have chosen any distinct name for each the various levels. Having said that, it
is useful to choose labels which it is easy for people (hopefully many) to relate to.
Before choosing this terminology, we looked at contracting practices in various
communities around the world. In particular, we looked at the words which
are actually used in contracts - in headings, in cross references, and in
interpretation clauses.
What we found is that while certain words like clause, article, section, paragraph, sub-paragraph,
subparagraph, sub-clause, sub-article, and item often show up, there is
no consistency to what words are used in what contracts. In fact, few (if any) law
firms even use the terminology consistently themselves across the contracts they
produce!
We chose the Article, Section, Paragraph hierarchy, because it is quite familiar
to a large number of lawyers, especially north American lawyers.
In some other countries, every paragraph is referred to as a clause. This suggests
a so-called 'recursive' model may be desirable. However, for reasons given elsewhere
in this FAQ, a hierarchy with distinct names for each level is to be preferred.
- What is the difference between 'Paragraph' and 'paragraph'?
Mere convention. Where a word like that is capitalised, it refers to an XML element
name. Where it appears in lower case, it is used in a more general sense.
- What? I don't use 'article'!
You don't need to worry, since the word 'Article' won't be visible in the
text of your contract, unless you put it there.
The word 'Article' is only used in the XML element names, which neither you
nor your clients need ever see. You don't need to see it, because you can choose a
word processor or XML editor which is programmed to display your own preferred terminology instead.
- So consistency is important, is it?
Absolutely. Unless people around the World use the same element names for
the different levels of clauses in their contracts, contracts drafted in
one country won't be able to be opened in the tools used in another, not
without conversion anyway.
This argument applies with even greater force within any given community of
contracting parties.
- There is no way I'll play along with 'Articles'
Okay then .. If you insist that the only standard you will use is one that uses your
own terminology for the element names, and you can find a lot of other people
who also use that terminology, and you believe there are compelling
reasons for supporting your terminology in the standard (ie tool support for
your terminolgy is not enough), then please let us know. We will consider
your ideas for a future version of our standard.
- What does this clause model simplify?
Three things, mainly.
First, it uses terminology which a lot of lawyers already use, so less training will
be needed. We expect other lawyers will readily adapt to it. Because the hierarchy is
simple (one term per level) and strict (a term can only be used at the appropriate level),
lawyers are spared a bewildering range of unnecessary elements when
drafting.
Second, the XML reflects natural document structure. So when a lawyer editing a contract
moves an Article from one place to another, the editing application is easily able to
move all its child sections and their paragraphs along with it.
Third, in order to make the XML in to human readable contract, a stylesheet is
required. Our clause model makes these stylesheets easy to produce and maintain. It achieves
this important goal by having only one element name at each level, and by using a different
name for that element for each level.
- What word processor should I use?
You can use any XML Editor which supports W3C XML Schema. For example, Altova's Authentic
editor or XML Spy, Microsoft's forthcoming Office 2003 Pro, SpeedLegal's SmartEditor, or
the contract editor in certain contract management systems (for example, TBC).
However, with some of these tools, you might find it painful to move a clause
from one level of the hierarchy to another. For example, to move a 'Paragraph'
up to become a 'Section'. The reason for this is that for the contract to stay valid,
the 'Paragraph' element needs to be renamed 'Section'. You either need to make this
change manually, or use an editor which does it automatically for you.
- The developers are asking why you didn't use a 'recursive' model?
Yes, a recursive model would make certain things easier (for example, promoting and demoting clauses around
in an editing scenario). But it is harder for lawyers and other end users to work with,
and more expertise would be required to create and maintain transformations. So balancing the various
considerations, we've decided a non-recursive model is best.
![[Valid HTML 4.01!]](/images/vh40.gif){kind=small}