| Name | Data Consortium Requirements - Contract Information |
| Principal Stakeholders | Commercial Real Estate Industry |
| Scenario Owner | John McClure |
| Draft Number | 1 |
| Draft Date | 31 January 2003 |
| Contributors |
This document contains requirements from the Data Consortium (http://www.dataconsortium.org) that we request be implemented by the initial standard being crafted by the OASIS LegalXML eContracts Technical Committee. The Data Consortium represents the commercial real estate industry in the United States, and is allied with the PISCES organization, a similar group of commercial real estate stakeholders in the United Kingdom and Europe. The Data Consortium also has extensive ties within the United States to fraternal groups, most notably the Appraisal Institute and the National Council of Real Estate Investment Fiduciaries.
All members of the Data Consortium have a strong interest in the standards being developed by the OASIS LegalXML eContract Technical Committee because significant savings and new services are expected in our industry as a direct result of creating a standard that supports an arms-length exchange of contract documents. Our request for consideration of our requirements is made as a fellow OASIS organization and, accordingly, we offer our services and industry experience to the Technical Committee as it moves forward from the requirements process through implementation and standardization.
We expect to submit a companion "use case scenario" which is concerned with the extraction of information from a legal contract.
As per the requirements process, contributions to this scenario are welcome. Please send your contributions to John McClure. The preferred format for comments is a marked-up version of this document, using <ins> and <del> elements to identify text changes you'd like to see.
The objective of this scenario is to identify the information in a contract which the Data Consortium wants to extract, usually for reason of updating databases concerned with the management of real estate properties and facilities. The information elements identified here are those contained within the contracts themselves, that is, this document has merely a passing interest in process-related information as it occurrs during the formation and administration of the contract. Rather, the focus here is entirely on the content of the contract as agreed to by the parties.
There are numerous legal documents involved with the daily conduct of commercial real estate operations. Our focus here is on our two bedrock documents — leases and purchase contracts — which we believe would herald the industry's greatest and most immediate benefit from following a standardization process. We are interested in standards that relate to not only the original contract but, in the case of leases, also to contract renewals. In fact, leases themselves can be considered almost to be an archetype for most other contracts, because (a) leases detail a recurring relationship over time between the parties, not just a to a specific action, as in a transfer of property (b) leases do often include purchases or expectations of goods and services between lessor and lessee (c) leases do involve the specification of rights that are granted by the lessor to the lessee (e) leases can include debt instruments such as promissory notes (f) leases have discernible contract execution, performance, settlement, renewal, and default terms and (g) many lease contracts include options to purchase, or a grant of purchase.
What does the real estate professional do, today, with the executed lease contract? The most common answer is that the scope of information then abstracted from the contract is dependent on the schema of the databases that are to be updated. Most databases in the commercial real estate industry today are relational databases, that is, they are a rigid information structure which do not accommodate the flowed text which this group expects to annotate with XML markup. In short, the industry transfers selected fields of information from the contract to databases that drive facilities management and accounting functions.
Clearly, this process can be improved by converting the contract into a database itself that drives the facilities management and accounting functions of a commercial real estate management company. In order for this to happen, however, all information in the contract must be annotated with XML tags. Often, certain information in the contract serves multiple purposes and, hence, this information must be simultaneously tagged with multiple XML tags. By doing so, introduction of new or improved services will no longer depend on the information abstracted from a contract, because that step will have been eliminated.
The following requirements have been determined from analysis of the structure and content of commercial real estate leases.
Contracts range from simple memoranda of renewals to multi-section, multi-addendum, masterpieces of legal artistry. One important aim of the schema for a Contract is to avoid forcing drafters of simple contracts to structure their contracts in a manner appropriate only to complex contracts. Complex contracts require a higher degree of normalization (of "nesting") of their information, primarily to facilitate formatting the document for printing and viewing. Simple contracts however, have little need other than to directly identify the parameters of the contract, without the "embedding". For instance, the Body of a Contract can be explicitly stated, complete with embedded text, or it can be implied for text embedded at the level of the contract itself.
<xsl:template mode='Validate' match='x:Contract'>
<xsl:apply-templates mode='Error' select='.[
count(x:BackMatter)>1 or count(x:Body)>1 or count(x:FrontMatter)>1
or
count(x:*[local-name()!="Addendum" and local-name()!="Attachment" and
local-name()!="Clause" and local-name()!="Paragraph" and
local-name()!="Section" and local-name()!="BackMatter" and
local-name()!="Body" and local-name()!="FrontMatter"])>1]' />
<\xsl:template>
An amount string is a decimal string that is to be interpreted as an amount of currency. The specific currency is indicated either by the currency associated with the item's container or the datastream itself. A more specific set of elements indicating a specific currency, is provided at http://www.hypergrove.com/Publications/Symbols.html. For example, amounts in US Dollars would use "usd" rather than "amount".
A date string, as defined by XML Schema, is a string conforming to CCYY-MM-DD format.
A dateTime string, as defined by XML Schema, is a string conforming to CCYY-MM-DDTHH:MM:SS format.
A gDay string, as defined by XML Schema, is a string whose content ranges from 1 through 31.
A gDay string, as defined by XML Schema, is a string whose content ranges from 1 through 12.
A gYear string, as defined by XML Schema, is a string whose content ranges from 1 through 9999.
A name string identifies the "name" associated with an information object. For instance,
to show that "Mr. Jones (defined as 'Agent.2') is the agent for Mr. Smith (who is defined as 'Buyer.1'), and
Mr. Smith's agent is Mr. Jones" would be coded as:
<Agent>
<name>Agent.2</name>
<Name><en>Mr. Jones</en></Name>
<Buyer><nameRef>Buyer.1</nameRef></Buyer>
</Agent>
<Buyer>
<name>Buyer.1</name>
<Name><en>Mr. Smith</en></Name>
<Agent><nameRef>Agent.2</nameRef></Agent>
</Agent>
<Payee><nameRef>Agent.2</nameRef></Payee>
A string that identifies the "name" associated with a referenced information object. See name for more information.
A text string contains a separately addressable set of text characters. The specific language of the text string is indicated either by the language associated with the container or the datastream itself. A more specific set of elements indicating a specific language, is provided at http://www.hypergrove.com/Publications/Symbols.html. For example, strings of English text would use "en" or "eng" rather than "text".
A time string, as defined by XML Schema, is a string conforming to HH:MM:SS format.
A uri string identifies the Universal Resource Identifier of an information object.
An Addendum is located either within BackMatter or the Body of a Contract; within the Contract itself; or within another Addendum. Often an addendum is separately paginated from its surrounding material. Functionally, an Addendum can be either a "container" for another contract, or it may be itself a contract. As a contract itself, it is composed of all the information specified for a Contract, and as a container, it would merely contain a (single) Contract within it. When the Addendum contains a Contract, it may not simultaneously contain other information.
An AddressLine contains a text string.
A HomeAddress contains the same items as an Address.
A CityName contains a text string.
A StateName contains a text string.
A StatePostalCode contains a text string.
A WorkAddress contains the same items as an Address.
A ZipCode contains a text string.
An Attachment is located either within BackMatter of a Contract or an Addendum to the Contract; or within the Contract itself. Often an attachment is separately paginated from its surrounding material. Functionally, an Attachment contains material that may be germaine to the contract, but is not part of the contract between its parties. An Attachment can be a legal exhibit such as a Certificate of Occupancy or it can be a non-legal exhibit such as a drawing. Because the attachment is not a part of the contract, no attempt is made here to identify contractual terms or contractually-relevant declarations within it. Nevertheless, for the purposes of formatting the contract with its included attachments, its document parts are identified.
BackMatter in a Contract, Addendum, or Attachment identifies material that is often separately paginated from its FrontMatter and Body.
A Body in a Contract, Addendum, or Attachment identifies material that is often separately paginated from its FrontMatter and BackMatter.
A Clause is located in a Contract, Attachment or Addendum; in a Section of a Contract, Attachment, or Addendum; or within a SubSection of a Section.
A Caption normally contains a single text string, but can contain multiple text strings, each in a different language.
A CaptionNumber contains a single text string.
A SubClause is located in a Clause within a Contract, Attachment; Addendum; Section or SubSection.
A Contact is located within a Contract, Addendum, or Attachment. This schema also applies to all the roles defined below, including Agent, Author, Beneficiary, Buyer, Carrier, Claimant, Claimee, Editor, Invoicee, Invoicer, Landlord, LegalParty, Manager, Owner, Payee, Payer, Recipient, Renter, Seller, and ServiceProvider.
An Agent is a type of Contact, and inherits all its characteristics. Additional items are noted here.
An Author is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Beneficiary is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Buyer is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Carrier is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Claimant is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Claimee is a type of Contact, and inherits all its characteristics. Additional items are noted here.
An Editor is a type of Contact, and inherits all its characteristics. Additional items are noted here.
An Invoicee is a type of Contact, and inherits all its characteristics. Additional items are noted here.
An Invoicer is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Landlord is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A LegalParty is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Manager is a type of Contact, and inherits all its characteristics. Additional items are noted here.
An Owner is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Payee is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Payer is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Recipient is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Renter is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A Seller is a type of Contact, and inherits all its characteristics. Additional items are noted here.
A ServiceProvider is a type of Contact, and inherits all its characteristics. Additional items are noted here.
Content is located within a Clause, UnOrderedContent, Paragraph, or Section; or within a SubClause, SubParagraph, SubPart, or SubSection. Its primary function is to hold text strings that comprise the "body" of the text block.
A Date includes a year, month, day. Subtypes of a simple date include AsOfDateTime, ContractDateTime, CreateDateTime, LastEditDateTime, BeginDate, EndDate, BeforeDate, NotBeforeDate, AfterDate, and NotAfterDate.
An AfterDateTime inherits items from Date.
An AfterDateTime inherits items from DateTime.
An AfterTime inherits items from Time.
An AsOfDateTime inherits items from DateTime.
A BeforeDate inherits items from Date.
A BeforeDateTime inherits items from DateTime.
A BeforeTime inherits items from Time.
A BeginDate inherits items from Date.
A BeginDateTime inherits items from DateTime.
A BeginTime inherits items from Time.
A ContractDate inherits items from Date.
A ContractDateTime inherits items from DateTime.
A ContractTime inherits items from Time.
A CreateDateTime inherits items from DateTime.
An EndDate inherits items from Date.
An EndDateTime inherits items from DateTime.
An EndTime inherits items from Time.
A LastEditDateTime inherits items from DateTime.
A NotAfterDateTime inherits items from Date.
A NotAfterDateTime inherits items from DateTime.
An NotAfterTime inherits items from Time.
A NotBeforeDate inherits items from Date.
A NotBeforeDateTime inherits items from DateTime.
A NotBeforeTime inherits items from Time.
A Figure is located within a Clause, UnOrderedContent, Paragraph, or Section; or within a SubClause, SubParagraph, SubPart, or SubSection. Its primary function is to hold text strings that comprise the "body" of the text block.
FrontMatter in a Contract identifies material that is often separately paginated from the Body of the Contract.
An IndexTable is used to represent tables of contents, attachments, addenda, authorities, footnotes, keywords, references, and related documents, using the Type element.
Metadata in a Contract, Addendum, or Attachment identifies material that is normally not formatted into the web page or printable view. Dublin Core information items are placed here.
A Name identifies a simple name for something. Subtypes of simple names are included here.
A FullName is used to name a person.
A LegalName is used to name a person or other legal entity.
A BusinessName contains a single text string.
A FamilyName contains a single text string.
A FirstName contains a single text string.
A GivenName contains a single text string.
A GroupName contains a single text string.
An InstitutionName contains a single text string.
A LastName contains a single text string.
A MiddleName contains a single text string.
A NamePrefix contains a single text string.
A NameSuffix contains a single text string.
An OrganizationName contains a single text string.
An OtherName contains a single text string.
A Page is located within a Contract, Addendum, Attachment; or within BackMatter, Body or FrontMatter of a Contract, Attachment, or Addendum.
An EndTextItem is a reference to the last text string on a Page or in a PageArea.
A PageArea is located on a Page.
A Paragraph is located in a Contract, Attachment or Addendum; or in a Section or SubSection, Clause, or SubClause of a Contract, Attachment, or Addendum.
A SubParagraph is located in a Paragraph, Section or SubSection within a Contract, Attachment, or Addendum.
A Section is located in a Contract, Attachment or Addendum.
A SubSection is located in a Section within a Contract, Attachment, or Addendum.
A Table is basic content like Content, which holds string data, Figure, which holds image data, and List, which holds a set of strings.
A Cell occurs within a Column, Row, or Row. Within the context of a Table, it is to be flowed.
A Column occurs within a Table.
A Row occurs within a Table.
UnOrderedContent is located within a Clause, Paragraph, or Section; or within a SubClause, SubParagraph, SubPart, or SubSection. Its primary function is to hold text strings that comprise the "body" of the text block.