]>
&name; &version; XML HTML PDF (A4) {OASIS Document Number} http://docs.oasis-open.org/legalxml-econtracts/CD1/legalxml-econtracts-specification-1.0.xml http://docs.oasis-open.org/legalxml-econtracts/legalxml-econtracts-specification-1.0.xml None OASIS LegalXML eContracts TC specification eContracts Version 1.0 LaurenceLeff Individual
mflll@wiu.edu
 PeterMeyer Individual
pmeyer@elkera.com.au
 21 December 2006 2006 OASIS Open, Inc. All Rights Reserved. This is the specification for the OASIS eContracts XML 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 TC envisages that the primary use of the eContracts Schema will be to facilitate the maintenance of precedent or template contract documents and contract terms by persons who wish to use them to create new contract documents with automated tools. Use cases covered include negotiated business contracts, ticket contracts, standard form business and consumer contracts and click-through agreements. Status This document was last revised or approved by the LegalXML eContracts Technical Committee on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule. Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/legalxml-econtracts. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/legalxml-econtracts/ipr.php). The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/legalxml-econtracts. Notices
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. Copyright © OASIS Open 2006. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Purpose and Scope
Mission of the eContracts TCThe 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."
Scope 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.
Feature summary for the eContracts Schema Features of the eContracts Reference Schema can be summarized as follows: Contract documents are composed of paragraphs and clauses that may be stored separately and reused in multiple documents. The eContracts Schema defines these objects as containers that can be processed as distinct objects or content chunks for storage and retrieval in document assembly and other processing systems. The eContracts Schema uses the XInclude standard to support content sharing and reuse of clauses using the item element. The TC has aimed for simplicity with the eContracts Core Schema. It defines only 51 elements. Most content can be created with just a handful of elements: item, title, block and text with the item element used recursively. This is intended to make it easy to convert existing content to the eContracts Schema and permit content components to be inserted without re-tagging at any desired level of the document hierarchy in document assembly applications. The eContracts Core Schema defines the generic, hierarchical structure of contract documents. This provides the maximum flexibility for content reuse, reliable automated processing and transformation of eContracts XML into other formats. The eContracts Core Schema provides for embedded data values to support variables substitution in contract preparation and the extraction of data values from XML contract documents. This is achieved through the field element. This version of the eContracts Schema supports only the string type for the field element. It is anticipated that future schema versions may require richer data types, according to specific business requirements. The eContracts Reference Schema provides a mechanism to support conditional processing of content at the element level and within text contexts. This model is not part of the eContracts Core Schema to allow users to adopt their own conditional text processing model. The eContracts Core Schema provides a model for users to add metadata at the contract and clause level. The schema makes provision for common metadata fields required by document management, document assembly and publishing applications such as: document identifiers, the author, version and dates; the legal subject matter or categorisation of distinct content objects. The schema provides sufficient definition of content objects in contract documents that user applications can: define and apply automatic numbering schemes to those objects; generate desired renditions, including but not limited to print, RTF, PDF, HTML and text to speech ready formats. The eContracts Schema allows for an entry of various kinds of values into instances of contract documents based on that schema, e.g. dates specifying start and end dates of the contracts into their respective slots. This is achieved through the field of the Schema, which can be regarded as a slot for entry of specific values into contract instances, either by the user or by a back-end system. This version of schema supports only string type for the field element and it is anticipated that future schema versions would require richer data types, according to specific busines srequirements.
Benefits of the eContracts Schema 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: It will enable large volumes of contract precedents to be managed without concern about changes to proprietary file formats. It will avoid the costs associated with the periodical reformatting of proprietary data with embedded formatting information. It will allow off-the-shelf XML based content management and processing tools to be used for the creation, maintenance and retrieval of contract precedents. It will enable enhanced levels of automation in the assembly of contracts from precedents and from stored transaction data. It will enable contract precedents to be transformed into any desired rendition such as HTML, RTF, Microsoft Office Open XML format, OpenDocument or any other format. It will enable organizations to enhance precedents with metadata to facilitate improved information retrieval.If supported by vendors of document assembly and other automation systems, it will minimize dependencies between contract precedents and processing systems to reduce setup and switching costs.
Terminology The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in . application programmer The person or person(s) developing a system that examines or parses the XML conforming to this specification, or a version customized according to the recommendations herein. This would include the developer of style sheets developed in a style sheet language such as XSLT, whether they be used for producing a rendition or other XML XSLT. contract An agreement between parties that is intended to be legally enforceable. A contract may be oral, partly oral and partly written or wholly recorded in writing. The terms of a contract may be contained in many contract documents. contract document A document that records some or all of the draft or agreed contract terms. Contract terms are traditionally expressed in a natural language but it is assumed that some or all of the terms of a contract could be expressed in a deontic contract language (q.v.). deontic contract language Means a language that can express the rights and obligations of parties to a contract in a form that can be parsed by software applications and processed with other data to determine state information about matters governed by the contract. embedded data value This refers to a piece of information such as a product or service description, date, name, address, quantity or monetary amount that is embedded in the natural language expression of the contract terms. machine readable information This is information in the contract document that refers to information about contract rights, obligations, or states, that can be extracted from the document by a computer system. It includes information represented in deontic contract language, contract metadata and embedded data values. It does not refer to the computer readable characters in the text unless the meaning of that text can be determined by a computer sytem. For example, a monetary amount that can be read from the text is not machine readable information unless the system can determine useful information about the statement of that amount in the contract such as who must pay it, to whom it must be paid, at what time is it to be paid and for what purpose is it paid. natural language This includes the mode of expression of contract narrative as it is commonly written by lawyers. precedent contract This is a document that is used by the drafter of a new contract document as a starting point or template to assist in creating that new contract. rendition The output of a transformation or styling process by which XML documents conforming to a particular schema are rendered with human-readable layout in a particular format such as RTF, PDF, HTML or displayed by a computer using a particular kind of software. schema customizer The individual providing for changes, particularly additional elements or attributes to meet the needs of a set of users, e. g., a particular vertical market. As recommended in , this would probably be done in the file eContracts-Reference.rnc or an equivalent file. TC This refers, in this document, to the Organization for the Advancement of Structured Information Standards Legal XML member Section eContracts Technical Committee. transaction An instance of doing business, whether electronic or conventional.
Overview of the eContracts Schema
Generic structural markup model The TC considered various approaches to development of a schema for natural language contract documents, including: presentation based schema such as the Microsoft Office Open XML format and OASIS OpenDocument; simple web presentation schema such as XHTML 1.0; generic structural markup schema such as DocBook, DITA, TEI, XHTML 2.0 and others. 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.
Reliance on existing XML standards 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.
Normative schema syntax 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.
Name Spaces 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: http://purl.org/elements/1.1 - for the Dublin Core Meta Data set (dc) http://www.w3.org/2001/XMLSchema (xs) http://relaxng.org/ns/compatability/annotations/1.0 (a) http://www.w3.org/2001/XMLSchema-datayptes http://www.w3.org/2001/XInclude (xi), World Wide Web Consortium XML Inclusions Recommendation This namespace: urn:oasis:names:tc:eContracts:1:0 (ec)
eContracts Schema files The eContracts Reference Schema is currently packaged as these four files: eContracts-Reference.rncThis file defines the eContracts Reference Schema. It incorporates the other files in the schema package and sets various values for eContracts Reference Schema. These are:It activates conditional text and defines the elements used for conditional text in the schema. This permits users to easily substitute their own conditional text models.It activates XInclude for content reuse.It activates additional features that are required to meet the Web Content Accessibility Guidelines.References in this specification to "eContracts Reference" are to the schema defined in this file. eContracts-core.rnc This file defines all the elements and attributes in the eContracts name space, including the contract element. These definitions can be overridden in the eContracts-Reference.rnc file (or an equivalent file) to create a user customization.References in this specification to "eContracts Core Schema" are to this file. References to "eContracts Schema" are to any schema that incorporates this file, with or without customization, provided that the customization complies with the naming conventions in . dc-metadata.rnc This file incorporates some basic elements from Dublin Core in the metadata element at the beginning of the contract. xi-include.rnc This defines the xi:include element from World Wide Web Consortium XML Inclusions recommendation.
Data exchange and normative use of the eContracts Reference Schema 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:Most attributes are defined as xsd:string (CDATA) in the eContracts Core Schema so that any value provided in a user customization is valid.Loose content models are defined as default values in various contexts in the eContracts Core Schema so that tighter content models defined in user customizations will be valid.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 , if those patterns are changed, the resulting schema must not use a name that designates it as part of the eContracts Schema family.
Basic building blocks in the eContracts Core Schema
The main document hierarchy 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: Numbered document hierarchy with and without titles 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: Markup of numbered hierarchy <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>
Use of item for clauses and lists 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: Example showing item as clause and as list items <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.
Paragraph markup with block and text 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.
Examples, explanatory notes, quotations etc. 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.
Core patterns for item, block and inclusion 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: A tight structure model permits either block or item but does not allow both at the same hierarchical level. It is represented as follows: tight.structure.model = inclusion*, ((block, inclusion*)+ | (item+, inclusion*))? A standard structure model permits block elements before the first item but not otherwise at the same hierarchical level. It is represented as follows:standard.structure.model = inclusion*, (block, inclusion*)*, (item+, inclusion*) A loose structure model permits block and item to be mixed in any order at the same hierarchical level. It is represented as follows: Loose structure model loose.structure.model = (block | inclusion | item)* 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 Document Structure in the eContracts Schema
Components of <sgmltag>contract</sgmltag> contract is the root tag for contracts. A contract MAY contain the following, each of which is discussed in more detail below: metadata title and subtitle - the contract writer MUST include a title. contract-front body - this MUST appear back attachments 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: A Simple Contract <?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. A Simple Contract 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>
Particular features of the eContracts Schema
About this section This section explains particular features of the eContracts Schema that are not easily gleaned from the Language Reference. Refer to the Language Reference for the specification for each element of the schema.
Managing metadata The eContracts Core Schema provides a metadata element for the contract and item elements. The content of this element is not defined in the eContracts Core Schema. Users of the eContracts Schema are free to define metadata to meet their specific needs.However, eContracts Standard incorporates basic elements from Dublin Core from the name space http://purl.org/dc/elements/1.1.
Numbering of structural provisions such as item and attachment In contracts, it is common that structural provisions such as items and attachments are numbered. The eContracts Core Schema provides the number attribute on the elements item, attachment and inclusion to support numbering.The eContracts Core Schema makes no assumption about the way that numbers for those provisions will be generated. Numbering must be handled in each application.The eContracts Core Schema provides attribute placeholders on the root element and other containers so that users can add attributes to control numbering if it is implemented in the XML data.
List item numbering Within a block, an item will be considered to be a list item. The block provides the number-type which is used to control the numbering or otherwise of list items. While expected values are defined for the numbering, the schema does not enforce this behavior in the application. It is up to user applications to enforce the specified numbering behavior. The number-type attribute defines the following values: manual The contract writer may enter a value for the number attribute on each of the item elements directly within this block. A application programmer MUST not alter the values found in the data. none A application programmer MUST not enter a value in the number attribute for the item. disc The application programmer SHOULD render list items by a disc or bullet. line The application programmer SHOULD render list items by a line or dash. number The applicaton programmer SHOULD render list items with preceding numerals ('1', '2', '3', ...) loweralpha The application programmer SHOULD render list items with preceding lower case alphabetical characters ( 'a', 'b', 'c', .... 'z', 'aa', 'ab', 'ac', 'ad' ... 'za', 'zb', 'zc'...'zz') upperalpha The application programmer SHOULD render list items with preceding upper case alphabetical characters ('A', 'B', 'C', ... 'Z', 'AA', 'AB', 'AC', 'AD'... 'ZA', 'ZB', ...'ZZZ') lowerroman The application programmer SHOULD render list items with preceding lower case roman numerals ('I', 'ii', 'iii', 'iv'...) upperroman The application programmer SHOULD render upper case roman numerals ('I', 'II', 'III', 'IV'...) The user application MAY include formatting characters such as parenthesis around list item numbers in the attribute values or it may provide those characters during rendering.
Conditional text processing Often, the creator of a form contract needs to provide for certain text to be included in certain circumstances. For example, certain riders in an in insurance policy may be included when the customer pays for them or each jurisdiction might happen to require only certain text or disclaimers. Conditional processing is very common in document assembly applications. However, there is no standard way for these applications to support the conditional markup or the processing logic. The TC decided it could not attempt to define a standard representation of conditional text processing in contract documents at this stage. The eContracts Core Schema defines a simple condition attribute for use on container elements and a conditional element for use with inline elements. However, it does not activate these values in the schema. Activation is provided in eContracts Reference. Thus, users can elect to use or not use the conditional processing model provided in the eContracts Core Schema. Condition values may be specified in the contract metadata using the conditions element. However, user applications may locate these values in any file or database that is accessible to processing applications. If the eContracts Schema is widely adopted, it may be highly advantageous to define a more powerful model to support conditional processing functionality provided by document assembly applications. The following example shows a simple use of conditions to control the rendering of items according to the jurisdiction that applies to the contract. An element may have multple values for its condition attribute. If so, it will be rendered if any one of these values is true. In this example, the jursidiction is set to jurisdiction-US. content for other jurisdictions will not be rendered. Showing the condition 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"> <metadata> <conditions> <condition name="jurisdiction-US">Jurisdiction United States</condition> </conditions> </metadata> <title><text>Sample of Conditions</text></title> <body> <block condition="jurisdiction-US"> <text>A United States - specific term in the contract</text> </block> <block condition="jurisdiction-AU"> <text>An Australia-specific statement in the contract</text> </block> <block condition="jurisdiction-AU jurisdiction-US"> <text> This block will be included if either value is true.</text> </block> </body> </contract>
Content reuse with XInclude The eContracts Core Schema permits content sharing and reuse using the xi:include element. This is for the item element only. Implementation of the XInclude functionality is provided in the eContracts Reference Schema. XInclude permits a user to link to any element as the target, regardless of whether it is valid at the designated location. If an invalid element is target, this will only become apparent when the document is validated after the xi:include links are resolved.
Party signatures
Scope of the eContracts Schema Many contracts that are to be physically signed by the parties using a pen and ink signature or seal require elaborate structures to record the names of the party, the persons signing and to provide places for actual signatures.The eContracts Core Schema makes provision for physical signatures on printed documents. It does not provide any specific mechanism for digital signatures to be represented in the XML markup of a contract document. The TC has not identified any business requirements for it to do so at this time. Parties can apply digital signatures for electronic transactions by applying those signatures to the electronic file that is used as the authoritative record of the transaction. Accordingly, the issue of digital signatures was considered outside the scope of the TC's mission.
Written signatures The eContracts Core schema provides two ways for the contract drafters to create signature information in contract documents :The party-signature element provides a semantic markup of party signature information that can record the name of the party, persons signing and witnesses. This markup permits signature information to be laid out in horizontal or vertical alignments in renditions from the XML.Signature information can be laid out in a table, if desired. The signature-line element is permitted in the table entry.Users may choose either approach according to their convenience and requirement for semantic markup. The use of the party-signature markup is described in detail in the Language Reference.
Invocation of the eContracts Reference Schema
Invocation for the Relax NG schema Users who propose to use tools with Relax NG support will need to look at the documentation for their specific tool.
Invocation for the XML Schema 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" > eContracts-Reference.xsd can be a full or relative path to the schema file.
Invocation for the DTD The DTD is invoked as follows: <?xml version="1.0"?> <!DOCTYPE contract SYSTEM eContracts-Reference.dtd> eContracts-Reference.dtd can be a full or relative path to the DTD file.
Customizing the eContracts Core Schema
Customization Introduction 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.
Classes of customizations for the eContracts Schema There are two classes of modification to the eContracts Schema:eContracts SubsetThis is a customization of eContracts Core using the eContracts-Reference.rnc file or an equivalent file. Contract data under a subset customization must be validated against the eContracts Reference Schema. This permits a subset customization to:add attribute value enumerations for xsd:string values andswitch between the loose, standard and tight content models.eContracts VariantThis is a customization of eContracts Core that cannot be validated against the eContracts Reference Schema. There are no restrictions on this type of customization, except that the integrity of the core patterns for item and block, including the loose, standard and tight content models found in eContracts-core.rnc must be retained if the schema is to retain designation as part of the eContracts Schema family. This class of customization may add new attributes to existing elements, add new elements and new document types.
Naming conventions for eContracts Schema customizations For an eContracts Subset customization, it is strongly recommended that the name be in the form:eContracts-s-application-name.rncFor an eContracts Variant customization, the schema customizer should use a name be in the form:eContracts-application-name.rncIf a customization is not an eContracts Subset or an eContracts Variant, it MUST not use "eContracts" as part of its name.
Changing content models in <filename>eContracts-core.rnc</filename> eContracts-core.rnc should never be modified directly. All customizations must be undertaken in a customization layer similar to eContracts-Reference.rnc.
Customizing for the loose, standard, and tight models. 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): Container Model Customization Table element Model to change bodybody.structure.modelbackback.structure.modelattachmentattachment.structure.modelitemitem.structure.modelinclusioninclusion.structure.model
 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
Customization 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.) Adding attributes and elements to the item element 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. Illustrates possible contract document after schema is customized. <?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: Container Model Customization Table element Label to change attachmentattachment.numbering.attributesbackback.numbering.attributesbackgroundbackground.numbering.attributesblockblock.numbering.attributescontractcontract.numbering.attributesentryentry.numbering.attributesinclusioninclusion.numbering.attributesitemitem.numbering.attributes
Creating XSD and DTD files 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.htmlTrang 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.xsdEach of trang.jar,eContracts-Standard.rnc, eContracts-Standard.xsd can be specified as a full or relative file path to the actual location of the file. Also, the above command must be typed as one physical line.
Contract Scenarios Considered by the eContracts TC A range of scenarios were presented by TC members to represent their interests in the TC's work. The main scenarios and the problems sought to be addressed are summarized in these Case summaries.
Case 1 – On-line click through transactionsBuyers of many goods and services must accept contract terms shown online before they can complete their purchase. Many of these contracts have ongoing effect.The stated problems: Party's transacting online may not know what contracts they have entered into. They will have great difficulty determining their obligations under those contracts. Consumers cannot easily compare terms offered by different providers.
Case 2 – Extraction of contract management dataMany contracts, such as construction contracts require parties to meet obligations and exercise rights at specified intervals or on the occurrence of events over a long period.The stated problems: There are frequent disputes over change authorisation in construction contracts and similar transactions where frequent variations occur. It is difficult to ensure all parties have reliable information about upcoming obligations under the contract. It is difficult to extract terms and embedded data values from the contract into content management systems. It is difficult to access the content of external documents that are incorporated into the contract. There is no reliable way to determine the state of contract events, obligations and processes. It is difficult to monitor and analyse performance of parties over extended time periods.
Case 3 – Contract precedent management and contract draftingLawyers rely heavily on precedent documents and documents from previous transactions when preparing new documents. It is common for lawyers to use document assembly and variables substitution systems when creating new documents.The stated problems: Contract documents are created using word processing applications. These documents can’t easily be processed at convenient levels of granularity by automated systems. Content components are not self describing. In addition to legal maintenance, precedent documents must be revised to deal with changing file formats and proprietary processing systems. This adds to the cost of maintenance. The absence of standard storage formats for contract narrative terms and documents means that it is difficult to process these documents outside the creating application. This creates proprietary ties between data and software applications. It frustrates the use of off-the-shelf tools. It also inhibits automated document creation, information reuse, information extraction and change traceability.
Case 4 – Represent contract semantics for machine processing of contract terms This case was really another approach to Case 2. Various models have been developed to define contract rights and obligations using formal languages that can be interpreted by computer systems (deontic contract languages). Contracts using deontic contract language could be useful in various contract management contexts from performance monitoring to dispute resolution. The stated problems: There is no standard deontic contract language that can be used for a wide range of contracts. There is no way to manage the relationship between deontic contract language and the natural language terms.
Case 5 – Define contract terms that would apply to a computer negotiated contract Contract negotiation is slow and expensive. The inefficiencies inherent in human contract negotiation limit the value of the transaction, particularly where rich parameter sets are involved. A program was developed by a member for computer negotiation of contracts with defined parameters. The stated problem: There is no standard way to map a given set of negotiated contract parameters to a unique set of contract terms.
Case 6 – Develop a taxonomy for contract terms Contract users at various stages in the contract life cycle and in various transactions wish to be able to identify contract terms by their legal subject matter. The stated problem: There is no standard framework for the description of contract terms using a taxonomy or other controlled vocabulary to support contract negotiation, document assembly and contract management.
Case 7 – Management of eCommerce contract terms Electronic commerce transactions are governed by a master contract. Current standards do not deal with the formation and management of these contract terms. The stated problems: In electronic commerce transactions there is currently no way to map or validate electronic transactions against their master agreement. There may be no way to automatically determine if there is a master agreement. Human negotiation of bilateral master agreements is too time-consuming.
Scope analysis
Four domains of contract documentation So as to understand the characteristics of contract documents that are common to the widest range of contract transactions, the TC divided contract documentation into four domains.
Natural language contract precedents domain
Description In law firms and many other environments, natural language contract terms are prepared and stored as a library of terms or draft contracts that may be incorporated into or used as a starting point for new contracts in many future transactions. These stored terms are commonly called precedents or templates. Often, the incorporation of these terms into new contract documents will involve the use of information retrieval and automated document assembly or document creation systems. The natural language precedents domain covers a variety of cases considered by the TC: Precedents may provide the starting point for contracts in which the natural language terms are negotiated in detail between the parties. Precedents may be used to generate contract documents with highly standardized transactions where there is little or no negotiation of natural language terms. Precedents may be used to define standard terms for contracts created in on-line business to consumer transactions. Precedents may be used to generate contract documents that result from computer negotiated contracts.Precedents may be required to provide human readable documents for contracts also represented in a deontic contract language.
Characteristics Key characteristics of documents in the natural language precedents domain include: Contract precedents are usually maintained in back-end systems for long periods of time. During that time, precedent terms often must be updated in response to changes in the law and other factors. processing. In addition, software versions and file formats for processing systems may change. Current models based on word processing formats impose high long term maintenance costs and are inflexible for use with processing systems other than those used to create them. Persons wanting to use the contract terms need subject information (metadata) about individual terms to facilitate access. It may be necessary to render natural language terms in a wide variety of output formats, including print, word processing formats and HTML. Natural language terms may be stored and processed as whole contract documents or as components that may be assembled into whole contract documents. Enterprises that maintain databases of contract terms and documents usually expend a great deal of effort to provide for the accuracy and consistency of the stored terms because of their central importance in effective service delivery. They represent a major investment by their creators.
Scope assessmentNatural language precedents can be maintained and processed into contract documents in all the contract domains identified by the TC. The TC concluded that an XML schema that models natural language contract documents and terms would benefit a wide range of enterprises who maintain contract precedents. The use of a purpose designed XML model to facilitate better long term storage and automated processing of precedent contract documents could be highly advantageous to many of these enterprises.
Contract drafting and negotiation domain
DescriptionThe contract drafting and negotiation domain involves the day to day preparation of original, contract narrative terms for specific transactions between identified parties, as undertaken by lawyers and others. Once the contract is formed, transactions under these contracts may be completed quickly or over many months or years. In the later case, the contract may govern the rights and obligations of the parties during a complex set of events over a long period.
Characteristics Currently, lawyers and other persons who draft contracts do so with desktop word processing software. The TC concluded, that for the foreseeable future, there is little likelihood that these people will materially change the tools they use. It is likely that word processing tools will begin to use XML file formats such as the Microsoft Office Open XML format (WordprocessingML) or OASIS OpenDocument. These word processing XML formats are presentation based XML formats in which the semantics of the data is mainly represented in styles. Such semantics cannot be validated. Lawyers and others who draft contract documents rely heavily on precedent documents and terms to provide complex wording and know how.During the contract negotiation process, the parties may exchange drafts in electronic form. Currently this is done by exchanging word processing documents or PDFs. Based on the TC's expectation of continued use of word processing software by contract drafters, the TC does not expect this to change.
Scope assessment The TC considered whether its schema should facilitate the exchange of contract data between parties to negotiations. The TC could not identify any basis for the foreseeable future in which the parties are likely to work with and exchange XML documents other than the word processing XML formats, as the use of those formats becomes more prevalent. The TC proposes that the eContracts Schema may be used for this purpose but this use is not expected to be commercially significant.The TC considered whether parties to a contract may use an XML document as the formal record or artifact of the contract terms. The TC concluded that the parties to negotiated contracts are likely to continue to use printed documents and other electronic formats such as PDF for formal records of contract terms. The TC was not given any convincing use case for the contracting parties to use an XML document as the formal record of contract terms outside of electronic business transactions already governed by other standards. Those transactions are outside the scope of the TC's charter.The TC considered whether it could develop a standard that would involve adding additional semantics to either or both of the common word processing XML formats. It concluded that the value of this is unclear at this time. Lawyers and others involved in contract drafting have little time or interest in adding markup to their documents. There is no reason to expect them to do so unless it is required by their clients. Even if in particular contexts they will do so, the TC could not decide whether it should work with the Microsoft Office Open XML format or OpenDocument. In the market place, there is likely to be ongoing competition between these XML formats. The TC concluded that the use of a generic structural XML schema for use in the stored precedents domain would provide the greatest flexibility and enable users to transform precedents into any word processing XML format. The TC considered whether it should attempt to develop a metadata or embedded markup model for use with one or both the word processing XML formats. The TC could not, at this time, identify commercially practicable requirements for a specification covering the contract drafting and negotiation domain.The TC concluded that this domain is best supported by a specification to facilitate the preparation, maintenance and use of natural language precedents to be used in the preparation of negotiated contracts.
Form contracts domain
Description This domain covers standard form contract documents in which there is little or no negotiation of contract terms. If negotiation occurs it is only to determine whether particular terms are included. It does not affect the natural language of any particular term. In on-line, business to consumer transactions assent may be manifested via a “clickwrap” mechanism. In cases where the contract document is printed, assent may occur by conduct or by signing a printed document as in many consumer finance and sale of goods transactions.
Characteristics Form contracts involve the use of standard natural language terms. The only variables are matters such as product description, quantity, price, delivery etc. In either an on-line environment or off-line, the consumer or an agent of the service provider enters transaction variables into a form to provide the additional information required for the complete contract.Many form contracts are likely to be generated from natural language precedents.
Scope assessment The TC did not identify business requirements specific to this domain. It concluded that this domain is best supported by a specification to facilitate the management of natural language precedents that can be used to generate form contracts in appropriate cases where there is potential to improve the presentation and management of contract terms for specific contracts.
Contract management domain
Description This domain covers the use of contract documentation after assent. Information may be derived from the contract documents to support contract management activities and dispute resolution. In this domain, contract documentation could exist in natural language, deontic contract language or in both forms.
Characteristics Currently, information required by contract management systems must be manually extracted from the contract documentation and entered into a database system. Alternatively, it is common in many standardized transactions, that transaction data is held in a database and used to generate standard form contract documents in the form contract domain. In those cases, there is no need to extract this data from a contract document. An XML deontic contract language could provide the means to communicate contract terms to a contract management system. Such an XML document would be as the means to communicate contract terms to a contract management system. It is likely that only highly standardized contracts would be prepared in a deontic contract language. The TC concluded that it is likely that the natural language contract documents and deontic contract language documents would be separate.
Scope assessment The TC considered that contract management information could be extracted from information suitably defined by XML markup in natural language contract documents or from contracts expressed in deontic contract language. However, for this to be effective, authoritative contract documents must be prepared in XML. The TC decided it could not develop a deontic contracts langauge at this time due to the absence of involvement of commercial interests in such a language. The TC concluded that it could only address the contract management domain if it is likely that natural language contract documents will be available in a suitable XML format. For the reasons considered in connection with the contract drafting and negotiation domain, the TC considered that XML documents are not likely to be used as the formal record of contract terms, except in very specific situations.In negotiated contracts the TC did not identify any change from current practice where a print rendition is likely to be the formal contract artifact. The XML document from which that contract is generated may not contain all contract terms. Some terms may be altered by hand on the printed document before signature. Even in highly standardized transactions, the TC was not satisfied on the information currently available that embedding markup for contract management purposes in natural language contract documents was likely to be of practical benefit. It is just as likely that contract management information will be maintained separately from the contract document. This might be achieved using a separate XML representation to facilitate communication between contract management database systems. The TC concluded that a specification covering stored precedents could provide benefits for the contract management domain for use with natural language contracts. It could provide the semantics to permit extraction of data values and other semantic information defined by the parties, if they so choose.
Language Reference
Common Attributes These attributes occur on all elements. They are summarized here once for brevity and to make the attributes that occur on many elements stand out. The id attribute allows an unique identifier to be added to any element in the contract. Note that this is defined as ID while references to it are not currently defined as an IDREF. This means that upon validation, there will be no error if a reference to an ID does not have a corresponding ID. This allows one to validate fragments of contract documents, particularly in clause libraries. The schema customizer MAY change this. common.attributes = id.attributes id.attributes = attribute id { xsd:ID }? common.attributes &= attribute xml:lang { xsd:string }? NameTypeDefault idxsd:IDnone xml:langxsd:string none The xml:lang attribute is added by eContracts.standard.rnc. This semantics of this attribute are defined by the XML Specification [xml]. Please refer to that specification.
Class Attributes This is a generic class attribute and is applied to all elements. The intention is that this attribute is redefined for specific needs on an element-by-element basis. This attribute is given here once for brevity and to make the attributes that occur on many elements stand out. standard.class = attribute class { xsd:string }? NameTypeDefault classxsd:stringnone
condition.attribute This is to enable conditional text. See the conditions element for a description of this functionality. This attribute is given here once for brevity and to make the attributes that occur on many elements stand out. condition.attribute = attribute condition { xsd:string }? NameTypeDefault conditionxsd:stringnone
orient.attribute This specifies whether the element contents should be rendered as portrait or landscape: orient.attribute = attribute orient {"portrait" | "landscape" }? NameTypeDefault orientxsd:string
common.number.attribute This allows the user to specify the number or other designator such as "a)" for item, attachment, inclusion and note. common.number.attribute = attribute number { xsd:string }? NameTypeDefault numberxsd:string
Stop-Contents Attribute This stops the generation of table-of-contents entries for the elements contained within this element. stop-contents.attribute = attribute stop-contents { "below" }? NameTypeDefault stop-contentsxsd:stringbelow
address
Synopsis
Content Model address has a mixed content model. address = element address { (inline.content | field)*, address.attlist } address.attlist = common.attributes, address.class.attribute, address.name.attribute, address.attlist.extensions address.class.attribute = standard.class address.name.attribute = attribute name { xsd:string }? address.attlist.extensions = empty inline.content = (inline.content.inner)* inline.content.inner = text | reference | em | statutory-em | strike | sub | sup | field inline.content.inner |= conditional address ::= Zero or More of text data (#PCDATA) conditional em field reference statutory-em strike sub sup
Attributes and
Description This can contain an entire address (see example under party). Or it may contain part of an address, with each part having an appropriate category (see example below).
Attributes and
Parents These elements contain address: text, person-record
ChildrenThe following elements occur inside address: conditional, em, field, reference, statutory-em, strike, sub, sup
See Also name, party and person-record
Examples Several address elements which together define all parts of an address <?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>Sample of : - contract-front - parties - party - person-record - name - address </text></title> <contract-front> <parties> <party> <person-record> <name>John Smith</name> <address class="street">2-198 Lamoine Avenue</address> <address class="city">Macomb</address><address class="state">IL</address> </person-record> </party> </parties> </contract-front> <body></body> </contract>
attachment
Synopsis
Content Model attachment = element attachment { metadata?, title?, subtitle*, (attachment.doctypes | attachment.structure.model)?, attachment.attlist } attachment.structure.model = loose.structure.model attachment.attlist = common.attributes, common.number.attribute, attachment.class.attribute, orient.attribute, stop-contents.attribute, attachment.numbering.attributes, attachment.attlist.extensions attachment.numbering.attributes = empty attachment.class.attribute = standard.class attachment.attlist.extensions = empty attachment.doctypes = contract ## Tight structure model tight.structure.model = inclusion*, ((block, inclusion*)+ | (item.reuse.model+, inclusion*))? ## Standard structure model standard.structure.model = inclusion*, (block, inclusion*)*, (item.reuse.model+, inclusion*) ## Loose structure model loose.structure.model = (block | inclusion | item.reuse.model)* item.reuse.model |= xiInclude attachment ::= Sequence of Zero or one metadata Zero or one title Zero or more subtitle Zero or one of: contract If loose model is selected, sequence of: Zero or more of: blockinclusion item xi:include If standard model is selected, sequence of: Zero or more inclusion Zero or more sequences of One blockZero or more inclusion Sequence of One or more choice of item xi:include Zero or more inclusion If tight structure model is selected, sequence of Zero or more of inclusion Zero or one of: One or more Sequences of One block Zero or more inclusion Sequence of One or more sequences of item xi:include Zero or more inclusion
Attributes , , , , and
Description This element is a container for a single attachment such as a schedule, exhibit or appendix to the contract. A key feature of the attachment is that it can contain a separate eContract as well as the standard narrative structures. This allows a contract to be included as an attachment to another contract. By default, this element uses the Loose structure model for narrative content. The structure model used for the attachemnt element may be changed to one of the other structure models defined in this file as part of a customization.
Attributes , , , , , and
Parents These elements contain attachment: attachments
Children The following elements occur inside attachment: , contract, inclusion, , metadata, subtitle, title, and xi:include
Examples Please see attachments
attachments
Synopsis
Content Model attachments = element attachments { attachment+, attachments.attlist } attachments.attlist = common.attributes, attachment.numbering.attributes, attachments.attlist.extensions attachments.numbering.attributes = empty attachments.attlist.extensions = empty attachments ::= One or more attachment
Attributes
Description This is the container for one or more attachment elements. This element may be used to separate or group the attached content for automatic number or layout purposes.
Attributes
Parents These elements contain attachments: contract
Children The following elements occur inside attachments: attachment
See Also: object and back
Examples: An attachments with a single attachment element <?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>Sample of - attachments - attachment - title - block - text </text></title> <body></body> <attachments> <attachment class="appendix" id="a1" number="15"> <title><text>Form of notice in Schema files</text></title> <block><text>They must be sent regular mail.</text></block> <block><text>Standard Schema <reference href="http://www.elkera.com" print-url="true"> can be read on the web easily!</reference>.</text></block> </attachment> </attachments> </contract>
back
Synopsis back -- contains elements that follows the body of the contract including signatures.
Content model back = element back { title?, ((back.structure.model | party-signature)* & date-block?), back.attlist } back.structure.model = loose.structure.model back.attlist = common.attributes, back.numbering.attributes, back.attlist.extensions back.numbering.attributes = empty back.attlist.extensions = empty back ::= Sequence of One or more of title Interleave of Zero or more of If loose model is selected, sequence of: Zero or more of: blockinclusion item xi:include If standard model is selected, sequence of: Zero or more inclusion Zero or more sequences of One blockZero or more inclusion Sequence of One or more choice of item xi:include Zero or more inclusion If tight structure model is selected, sequence of Zero or more of inclusion Zero or one of: One or more Sequences of One block Zero or more inclusion Sequence of One or more sequences of item xi:include Zero or more inclusion party-signature Zero or one date-block
Attributes
Description The back element contains content that follows the main provisions of the contract, such as signatures and other material. Material found in the back is not hierarchically part of the body. By default, this element uses the loose structure model for narrative content. The structure model used for the back element may be chagned to one of the other structure modes defined in this file as part of a customization.
Attributes
Parents These elements contains back: contract
Children The following elements occur inside back: block, inclusion, xi:include, and title
Examples The following shows the back within a contract including one possible way that signature material could appear. Back Tag with one signatory and their witness <?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>Sample of : - back - party-signature - signatory-group - signatory-record - signatory - signatory-line </text></title> <body></body> <back> <party-signature> <signatory-group> <block> </block> <signatory-record> <signatory id="T0001" xml:lang="ja"> <signature-line id="I0001" xml:lang="en_US"> <text>Mr. Signatory Jr.</text> <field>Field for a text.</field> </signature-line> </signatory> <witness> <signature-line id="I0002" xml:lang="fr"> <text>Ms. Witness Arcole</text> <field>Field for a text.</field> </signature-line> </witness> </signatory-record> </signatory-group> </party-signature> </back> </contract>
background
Synopsis
Content Model background = element background { title?, item.reuse.model*, background.attlist } item.reuse.model = (item) item.reuse.model |= xiInclude background.attlist = common.attributes, backgound.numbering.attributes, background.attlist.extensions backgound.numbering.attributes = empty background.attlist.extensions = empty background ::= Sequence of Zero or one title Zero or more occurences of choice of: item xi:include
Attributes
Description This contains recitals and other "background" information.
Attributes
Parents background appears inside: contract-front
Children The following elements occur inside background: item title xi:include
Examples Please see parties.
block block -- The container for a structural or grammatical paragraph.
Synopsis
Content model block = element block { (block.level.elements | element item { metadata?, title?, (block | inclusion)*, block.item.attlist } )*, block.attlist } block.level.elements = text.container.element | definition | table | inclusion text.container.element = \text block.attlist = common.attributes, block.class.attribute, conditional.attributes, block.numbering.attributes, block.attlist.extensions conditional.attributes &= condition.attribute block.numbering.attributes = block.number.type block.class.attribute = standard.class block.number.type = attribute number-type { ListItemNumberTypes }? ListItemNumberTypes = "manual" | "none" | "disc" | "line" | "number" | "loweralpha" | "upperalpha" | "lowerroman" | "upperroman" block.attlist.extensions = empty block ::= Zero or more of: textdefinition table inclusion item inside a block
Attributes Additional attributes: number-type(enumeration) "manual" "none" "disc" "line" "number" "loweralpha" "upperalpha" "lowerroman" "upperroman"
Additional Constraints If this block contains a number-type = manual, then the contract writer SHOULD manually nubmer each list item by putting a number attribute on each of the item elements directly within this block.
Description The block is the container element for a structural or grammatical paragraph. The actual text data of the paragraph is put in the text element. Within a block, an item will be considered an element of a list. A block MAY contain the text element directly, an item, as well as definition, table, inclusion, party or person-record.
Attributes Additional attributes: number-type number-type indicates the type of numbering or markers to be used on contained list items. (enumeration) "manual"The contract writer SHOULD indicate list items by putting a number attribute on each of the item tags directly enclosed within this block"none" The application programmer SHOULD render list items without any marker or number."disc" The application programmmer SHOULD render list items by a disc or bullet. "line" The application programmer SHOULD render listitems items marked by a line or dash. "number" The application programmer SHOULD render list items proceeded by numerals ('1', '2', '3', ...). "loweralpha" The application programmer should render list items proceeded by 'a', 'b', 'c', .... 'z', 'aa', 'ab', 'ac', 'ad' ... 'za', 'zb', 'zc'...'zz' "upperalpha" The application programmer should render list items proceeded by 'A', 'B', 'C', ... 'Z', 'AA', 'AB', 'AC', 'AD'... 'ZA', 'ZB', ...'ZZZ' "lowerroman" The application programmer should render list items as 'i', 'ii', 'iii', 'iv', ... "upperroman" The application programmmer should render list items proceeded by upper case Roman numerals ('I', 'II', 'III', 'IV', ...)
Parents These elements contain block: attachment definition inclusion item , note party-signature signatory signatory-group signatory-record witness
Children The following elements in occur in block: , definition inclusion block.item table text
Examples See .
body
Synopsis body - The body of the contract
Content model body = element body { title?, body.structure.model, body.attlist } body.structure.model = loose.structure.model body.attlist = common.attributes, body.attlist.extensions body.attlist.extensions = empty ## Tight structure model tight.structure.model = inclusion*, ((block, inclusion*)+ | (item.reuse.model+, inclusion*))? ## Standard structure model standard.structure.model = inclusion*, (block, inclusion*)*, (item.reuse.model+, inclusion*) ## Loose structure model loose.structure.model = (block | inclusion | item.reuse.model)* item.reuse.model = (item) item.reuse.model |= xiInclude body ::= Zero or one of title If loose model is selected, sequence of: Zero or more of: blockinclusion item xi: