eContracts Version 1.0

The eContracts TC's mission is to promote “the efficient creation, maintenance, management, exchange and publication of contract documents and contract terms.”

The TC did not seek to focus on any particular vertical segment of the contracts domain.

The TC considered a range of scenarios covering issues in many different contract domains. A summary of these scenarios and the TC's conclusions on the scope of its specification are set out in the appendix "Contract Scenarios Considered by the eContracts TC."

This is the specification for the OASIS eContracts Schema developed by the OASIS LegalXML eContracts Technical Committee. The eContracts Schema is intended to describe the generic, hierarchical structure of a wide range of contract documents.

The eContracts Schema defined in this specification aims to facilitate the storage, maintenance and processing of natural language precedents for contract documents and contract terms that may be used to create contract documents in a range of identified contract domains. The eContracts Schema provides a model that can be used by persons who maintain precedent or template documents that will be used in automated document assembly, document construction and publishing systems to create contract documents. Thus, it is expected it will be used mainly in back-end, automated processing systems, rather than by lawyers and others involved in day to day contract preparation.

The TC expects that automated processing of eContracts documents will require that eContracts XML is transformed into common word processing formats for use in word processing applications."

It is possible that persons drafting contracts may work in an XML editor with the eContracts Schema. However, the TC does not expect this practice to be widespread in the forseeable future. Lawyers and others involved in the day-to-day drafting of contract documents work with common word processing software using unstructured methodologies. This is not expect to change. Even as word processing applications become capable of using arbitrary XML schemas, the TC does not identify any impetus for lawyers and other persons involved in the drafting of contracts and other legal and business documents to change current practices and adopt structured authoring methodologies. Should that change occur, the eContracts Schema is intended to be highly suitable for that purpose.

Law firms and other enterprises who often commonly contract documents often may create other document types such as advices, correspondence and litigation documents. Many of these documents are prepared in essentially the same way as contract documents, using the same automation tools. All the principles applicable to a schema for contract documents apply to these other documents. The TC concluded that the eContracts Schema will define common content objects that can be adopted by another standards body responsible for developing a schema applicable to those other legal documents.

The eContracts Schema is not intended to overlap with the functionality provided by existing standards for electronic commerce or electronic business transactions. The eContracts Schema is intended to describe natural language contract documents, something not provided by existing standards.

The TC expects the initial eContracts Schema will be a foundation for further developments by communities with interests in specific industry domains or contracting domains such as enterprise contract management.

Features of the eContracts Reference Schema can be summarized as follows:

The eContracts Core Schema is expected to support the widest possible range of uses in back-end contract document processing systems. It provides a standards based schema to facilitate the long term storage and maintenance of precedent contract documents and terms by law firms and other enterprises who use contract precedents to prepare contract documents for specific transactions. It will enable these users to reduce maintenance costs, provide better access to information to contract drafters and provide more reliable automation of document assembly and publishing processes. It should promote the wider availability of automated document creation systems. In particular:

The TC considered various approaches to development of a schema for natural language contract documents, including:

The eContracts Schema is a generic structural schema. It is designed to model the patterns found in a wide range of contract documents. It aims to provide maximum flexibility for long term data storage, content reuse and automation.

The eContracts Core Schema elements describe the components common to most contracts and their hierarchical relationship. The eContracts Schema does not provide a vocabulary to describe the subject matter of specific contracts. Information about the subject matter of a specific contract can be provided in metadata or other markup defined by particular users.

The eContracts Schema relies exclusively on existing XML standards. It does not seek to define new processing models that can only be implemented if application vendors choose to implement relevant features.

Support for the simple conditional text processing model defined by the eContracts Schema can be implemented in user level applications, if desired.

The eContracts Reference Schema is provided in Relax NG compact syntax, XML Schema (XSD) and as a DTD. The Relax NG compact syntax version is normative.

The Relax NG compact syntax permits a high level of flexibility for customizing the schema and provides a level of human readability similar to that provided by DTDs.

The eContracts Core Schema uses features that cannot be represented in DTD syntax. For example, the item element is used both recursively and as a child of the block element. When used as a child of block, item is re-defined to prevent it from having a child item element. This cannot be enforced in the DTD version.

The eContracts Schema uses the following name spaces. A suggested prefix is also provided even though, of course, the use of any schema file may select the prefix they wish:

The eContracts Reference Schema is currently packaged as these four files:

The eContracts Reference Schema is intended to be the foundation upon which organization or application specific schema are built. It aims to provide the minimum definition that is likely to be common to the widest range of contract documents.

The eContracts Reference Schema is intended mainly for use with precedents in backend processing. For this reason and because many contracts will be prepared using word processing software, the TC has not identified any common business requirements for users to exchange eContracts XML between user organizations. Thus the eContracts Reference Schema is not a normative standard for the exchange of contract documents in XML. There is no requirement that parties must use eContracts Reference to exchange data or that it be capable of validating any user customization.

The eContracts Reference Schema does aim to provide the maximum level of interoperability between users that is consistent with their need to customize the eContracts Schema to their specific requirements. This is achieved in two ways:

The eContracts Schema can be customized and these values overridden in a user customization.

The TC expects that user communities with common interests in exchanging contract documents in XML will develop their own normative standard based on the eContracts Core Schema. The eContracts Core Schema is expected to be the foundation for a large family of related schema that shares common core patterns and can benefit from the use of common tools.

The heart of the eContracts Schema is eContracts-core.rnc. To maximize the level of interoperability between eContracts XML and processing tools, the core patterns from eContracts-core.rnc described in section "Basic building blocks in the eContracts Core Schema" are normative. As described in Basic building blocks in the eContracts Core Schema, if those patterns are changed, the resulting schema must not use a name that designates it as part of the eContracts Schema family.

In contracts, the basic unit of content is often called a clause or section. Usually it has a number, a title and a block or paragraph of text.

In the eContracts Core Schema, the item is the basic building block of the document hierarchy. It is a recursive element and represents structures that may be known in contracts as "chapters," "parts," "sections," "clauses" and "subclauses." As explained in the next section, the item element is also used to represent items in a list.

The TC used the term "item" to avoid terms that my have a particular meaning to some users and not others. It can be given a citation name in automatic numbering based on its context and prevailing conventions.

It is not uncommon for contract documents to contain structures similar to the following example, often in the same document:

1 First level
1.1	Second level
1.1.1	Third level
           Content under third level with title.
1.2	Second level
1.2.1	Content under third level without title.
1.2.2	More content under third level without title.

The eContracts Schema treats each of the structures at the third level as structurally the same regardless of the presence of a title. For this reason, the main container element in the eContracts Schema (item) has an optional title.

This example would be marked up as follows:

<item number="1"><title><text>First level</text></title>
<item number="1.1"><title><text>Second level</text></title>
<item number="1.1.1"><title><text>Third level</text></title>
           <block><text>Content under third level with title.</text></block>
</item></item>
<item number="1.2"><title><text>Second level</text></title>
<item number="1.2.1"><block><text>Content under third level without title.</text>
</block></item>
<item number="1.2.2"><block><text>Content under third level without title.</text>
</block></item></item></item>

In the eContracts Schema, lists are created by enclosing the item element in a block. While extreme cases are obvious, it is frequently difficult to distinguish between a list and a clause or subclause in contracts. Often it is based on the numbering style the writer wishes to apply. In the previous example, some may regard the items numbered 1.2.1 and 1.2.2 as list items, others as clauses and others as subclauses. The patterns for a clause and a list item are almost identical. The TC took the view that these distinctions are often a matter of author preference and that the use of distinct elements for clauses and list items only makes it difficult to reuse content in another document or context.

In the eContracts Schema, clauses, subclauses and list items all use the item element. The nature of the structure is inferred from its hierarchical location. Thus, an item enclosed by a block is a list item and should be numbered as such.

The following example shows the use of item for clause and list markup:

<item number="1"><title><text>First level</text></title>
<item number="1.1"><title><text>Second level</text></title>
<item number="1.1.1"><title><text>Third level</text></title>
           <block><text>Content under third level with title.</text></block>
</item></item>
<item number="1.2"><title><text>Second level</text></title>
<block><text>This is a two level list:</text>
           <item number="(a)"><block><text>First level list item.</text>
                  <item number="(i)"><block><text>Second level list item.</text>
</block></item>
                  <item number="(ii)"><block><text>Second level list item.</text>
</block></item>
			  </block></item>
           <item number="(b)"><block><text>First level list item.</text></block>
</item></block></item></item>

The eContracts Schema does not use a separate list container. Properties of the list, such as the number-type are controlled by an attribute on the containing block.

The concepts of ordered lists and unordered lists have not been adopted in the eContracts Schema. All lists are represented in the same way. The use of bullets or sequential numbering for lists is governed by the number-type attribute on the containing block.

Grammatical or structural paragraphs in contract documents are represented with the eContracts block element. The block is intended to encapsulate all content that is semantically part of the paragraph, such as lists, tables, graphics etc.

The eContracts Core Schema avoids mixed content within the block. Thus, it never contains character data directly. Character data for the paragraph is contained in the text element. The text element ensures control over character data that occurs after or between other elements within the block.

For example, contracts frequently have complex list structures with character data between lists in a parent block. The text element makes it easier to reliably represent and process these structures. In other cases, a formula may be followed by the word “where:” to introduce the definitions of formula components. The text element provides a means to control whether this continues in line rather than the default position of starting a new line for text objects.

The text element may be repeated to create new lines within a block. The text element should never be used as a paragraph element.

Contracts may include examples, explanatory notes, quotations and other similar content that may occur at almost any point in the document hierarchy. The eContracts Schema uses a single element called inclusion to encapsulate all such objects. The nature of the particular object is captured in the class attribute on the inclusion.

The key points about these objects is that they all may include paragraphs (block elements) or clauses (item element). The inclusion acts as a shield element to permit the content of these objects to be processed separately from the containing document hierarchy. Thus, these objects may have their own automatic numbering sequences and formatting in published renditions.

The use of a single element for all such objects simplifies the content models and core patterns in the eContracts Core Schema and makes it easier for users to customize the schema by adding new values to the class attribute.

The inclusion is also used to encapsulate graphics with titles and can be used to manage groups of objects such as tables.

The inclusion element occurs almost anywhere in the document hierarchy. It is not intended to be used as an alternative to the item to create narrative content. It is intended only to encapsulate distinct objects that require separate formatting or processing from the main content.

The inclusion element should not be confused with the xi:include element that performs a completely different function.

Commonly, the body part of a contract will consist of numbered items. In some cases, these items may be preceded by one or more blocks representing introductory paragraphs. In content that has a poor hierarchical structure created with word processing software, authors may introduce blocks between items or after the last item. Inconsistent hierarchical structures present obvious problems for readers of contracts. At a technical level they can make it difficult to create accurate contents listings, chunk content for web publishing and control automatic numbering of items.

Often it is necessary to incorporate content created by others into an inclusion or attachment.

The eContracts Core Schema permits users to control the strictness of item structures in any part of the document. It defines three basic patterns:

Please refer to the Language Reference for complete content models.

These models can be applied selectively within many of the major containers in the eContracts Core Schema, including body, back, attachment, inclusion and item. The default value in eContracts Reference is the loose structure model in all contexts. This ensures that eContracts Reference will validate any customization using tight or standard models. It is not intended as a recommendation that users adopt the loose model in all contexts in their own applications.

These patterns enable users to create their own customizations with new containers and incorporate the standard patterns from the eContracts Core Schema.

contract is the root tag for contracts. A contract MAY contain the following, each of which is discussed in more detail below:

The following example shows a skeleton of a contract to illustrate these parts. To illustrate the overall structure, many of the elements are empty that would normally contain text:

<?xml version="1.0" encoding="utf-8"?>
<contract xmlns="urn:oasis:names:tc:eContracts:1:0">

  <title><text>Sample of the five elements at level 1 </text></title>

  <subtitle>This file is to test : - title - sub-title - contract-front -
       date-block - parties - party - body - back -
              attachments - attachment
            </subtitle>

  <contract-front>
     <date-block>
       <date><em>Long time ago</em></date>
     </date-block>
     <parties>
       <party></party>
     </parties>
  </contract-front>

  <body></body>

  <back></back>

  <attachments>
    <attachment> </attachment>
  </attachments>

</contract>

The following exemplifies the important features in the XML produced for a contract as per this specification. On line 12, observe the contract-front containing the dates (date-block) and a list of the parties parties (line 17) to the contract. Before this is metadata (line 6), which contains non-printing information about the contract document.

The body shows how text is prepared using the standard model. One could have customized the schema for the tight or loose model. The body has several blocks followed by zero or more items. A block contains a text which acts as a "text container." In additon to the words of the contract, it contains elements to emphasize or format text (such as em, strike, sup), as well as marked up text for name, address, party). After discussing these, the specification discusses condition elements and condition elements that are used for providing alternative text for various paragraphs. Text containers can also contain elements to include text and the field to bring in text from an application or database.

The back at the end of the example has markup illustrates the party-signature element. This supports many options, corresponding to the many way those signing documents and their witnesses.

The attachment element is provided for appendices and other exhibits to the contract, e. g. blue prints in a construction contract or a detailed specification in a software development project. They contain block and item like the body; they, by default, use the loose model.

1: <?xml version="1.0" encoding="utf-8"?>
2: <contract xmlns="urn:oasis:names:tc:eContracts:1:0"
3:           xmlns:dc="http://purl.org/dc/elements/1.1/"
4:           xmlns:xi="http://www.w3.org/2001/XInclude">
5:
6:   <metadata>
7:     <dc:title>WIU Sample Contract</dc:title>
8:     <dc:creator>Julie Sasa</dc:creator>
9:   </metadata>
10:   <title> <text>Overall Example</text>
11:   </title>
12: <contract-front>
13: <date-block>Agreement dated:
14:     <field class="date" type="blank" name="contract_date" length="75mm">
15:             <?xm-replace_text {ec:field}?></field></date-block>
16: <parties><title><text>Parties</text></title>
17:     <party><person-record><name>ABC Ventures Limited</name> having
18:             its office at <address>100 Main Street, Sydney, NSW 2000</address>
19:            </person-record>, hereafter referred to as
20:                  "<term>General Partner</term>"
21:     </party>
22:     <party><person-record><name>John A. Doe</name> of
23:             <address>10 Ramrod Drive, Sydney, NSW 2000</address></person-record>
24:               and <person-record><name>John W. Smith</name> of
25:           <address>25 Pine Road, Plainsville, NSW, 0000</address>
26:             </person-record>, herafter collectively referred to as
27:                   "Limited Partners"
28:     </party>
29: </parties>
30: </contract-front>
31:
32:
33:  <body>
34:     <block>
35:       <text>A<sub>10</sub><em>Emphasized Text</em><strike>Struck out</strike></text>
36:     </block>
37:    <block> </block>
38:    <item>  </item>
39:    <item>  </item>
40:   </body>
41:   <back>
42:
43:     <party-signature>
44:
45:       <signatory-group>
46:
47:         <block> </block>
48:
49:         <signatory-record>
50:
51:           <signatory id="T0001" xml:lang="ja">
52:             <signature-line id="I0001" xml:lang="en_US">
53:               <text>Mr. Signatory Jr.</text>
54:               <field>Field for a text.</field>
55:             </signature-line>
56:           </signatory>
57:
58:           <witness>
59:             <signature-line id="I0002" xml:lang="fr">
60:               <text>Ms. Witness Arcole</text>
61:               <field>Field for a text.</field>
62:             </signature-line>
63:           </witness>
64:
65:         </signatory-record>
66:
67:       </signatory-group>
68:
69:     </party-signature>
70:
71:   </back>
72:   <attachments>
73:     <attachment class="appendix" id="a1">
74:       <title><text>Form of notice in Schema files</text></title>
75:       <block><text>They must be sent regular mail.</text></block>
76:        <item>  </item>
77:        <block><text>Note that one can interleave block and item arbitrarily
78:            when we have a loose model container</text></block>
79:      </attachment>
80:
81:  </attachments>
82:
83: </contract>

Users who propose to use tools with Relax NG support will need to look at the documentation for their specific tool.

The XML Schema is invoked as follows:

<?xml version="1.0"?>
<contract xmlns="urn:oasis:names:tc:eContracts:1:0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:eContracts:1:0:eContracts-Reference.xsd"
xmlns:dc="http://purl.org/dc/elements/1.1"
xmlns:xi="http://www.w3.org/2001/XInclude"
>

The DTD is invoked as follows:

<?xml version="1.0"?>
<!DOCTYPE contract SYSTEM
eContracts-Reference.dtd>

This section explains the mechanics of adding a customization layer to the eContracts Core Schema using the Relax NG files. It also provides naming conventions for user customizations to avoid confusion about what is and what is not part of the eContracts Schema family.

The TC anticipates that users will develop customizations [MIN0216]. Some of these customizations will be for vertical areas such as real estate where the PRIA and MISMA standards are in use. [MIN0119]. UBL provides 'a set of business elements' and one might wish to combine the standard described in this specification to provide narrative terms and use UBL, or similar standards, to document 'business terms.' The TC has chosen not to standardize how this might be done at this time.

The eContracts Reference is a convenient template for user customizations.

There are two classes of modification to the eContracts Schema:

For an eContracts Subset customization, it is strongly recommended that the name be in the form:

eContracts-s-application-name.rnc

For an eContracts Variant customization, the schema customizer should use a name be in the form:

eContracts-application-name.rnc

If a customization is not an eContracts Subset or an eContracts Variant, it MUST not use "eContracts" as part of its name.

eContracts-core.rnc should never be modified directly. All customizations must be undertaken in a customization layer similar to eContracts-Reference.rnc.

This section explains, how to customize the schema, to configure for loose, standard and tight models. Each of these is done by changing the appropriate grammar element in the main schema file (similar to eContracts-Reference.rnc):

Each of these elements can use either the tight.structure.model, standard.structure.model, or loose.structure.model. The following example sets all five text containers to use the tight structure model:

    body.structure.model        = tight.structure.model
    back.structure.model        = tight.structure.model
    attachment.structure.model  = tight.structure.model
    item.structure.model        = tight.structure.model
    inclusion.structure.model   = tight.structure.model

The [Relax], Section 9.2, shows how one can add to an attribute list or grammar. Customizations SHOULD be added to the eContracts-Reference.rnc or a renamed copy of that file. Then, add the lines needed to add the modifications you wish. This is illustrated below. (Some of the material from eContracts-Reference.rnc were removed to save space.)

The above shows how one can change to the tight model to add two attributes, a and b to the item element. These are added to block.item.attlist.extensions. Note that item is defined in two different places in eContracts-core.rnc

In addition, we added the I1 and I2 to the inclusion element, by updating the inclusion.class.attribute and inclusion.attlist.extensions, respectively. It also adds the attribute E to all elements.

<?xml version="1.0" encoding="utf-8"?>
<contract xmlns="urn:oasis:names:tc:eContracts:1:0"
          xmlns:dc="http://purl.org/dc/elements/1.1/"
          xmlns:xi="http://www.w3.org/2001/XInclude">

 <title>
   <text>Data validate agaist Loose model based on Mr. Meyer's email on Aug20.</text>
 </title>

 <body>
   <block> </block>
   <block> </block>
   <block>
   <item b="4"></item>
   <item a="3">
     <block><text><PaySomeone>3212</PaySomeone></text></block>
     <block></block>
   </item>
   <item E="5">
      <inclusion I1="9"></inclusion>
      <inclusion I2="10"></inclusion>
   </item>
    </block>
   <block> </block>
 </body>

</contract>

If the schema customizer wishes to add a customization to the item that might appear directly within a block tag, they change block.item.attlist. On the other hand, if one wishes to provide a customization to an item that might appear anywhere else, one adds it to item.attlist.extensions. In examining the definition of item in eContracts-core.rnc, one sees that one can add new elements to item by changing item.structure.module. It would have "worked" if the schema customizer added attributes by changing common.attributes, item.class.attribute, conditional.attributes, stop-contents.attribute, item.numbering.attributes, and item.attlist.extensions. However, these have special meanings and most are used elsewhere. Thus, the schema customizer SHOULD NOT make this change there. As you can see, the schema often uses the convention, element-nameattlist.extensions to add attributes to element-name. As another example, attachment.attlist.extensions is where the schema customizer MAY put additional attributes that are to appear in the attachment element. Many elements also provide a customization opportunity of the form element-name.class.list For example, the schema defines inclusion.class.attribute. Also, the following elements have places to enter numbering options:

After customizing the RelaxNG files, it may be necessary to create either an XML Schema (XSD) or a DTD, depending on the requirements of the user application.

Trang is available from www.thaiopensource.com/relaxng/trang.html

Trang is capable of creating an XSD file for the eContracts Schema. However, it will not create a DTD file for the eContracts Schema because of the redefinition of the eContracts item element in the block context. The DTD file must be customized manually.

The command to translate the schema to XSD using Trang is:

java -jar trang.jar -I rnc -O xsd -o any-process-contents=lax -o
any-attribute-process-contents=lax -o disable-abstract-elements
eContracts-Standard.rnc
eContracts-Standard.xsd