[legalxml-econtracts]

[John McClure <jmcclure@hypergrove.com>]

Hello,
Attached is a sample of the simplest markup structure possible - it is this that I am proposing be our standard for eContracts.
There are only 4 XML elements, and these contain a "names" attribute whose values are defined within one or more RDF Dictionaries:

1. <LegalXML> -  this element introduces the datastream
2, <LegalDocument> - this element introduces a document in the datastream
3. <en> - this element contains English text
4. <style> - this element contains the CSS styling directives for the document

The <en> element may contain mixed content -- english text plus child <en> elements. This element contains a "names" attribute that
holds one or more names assigned to the element which accord with the dictionary(s) specified for the datastream. This technique has
been shown to be effective when there are multiple information models at work in a document. In this case, there are 3 coexisting
models:

1. Document model -- identifies Dublin Core information for the document, eg title, creator, date, and other metadata
2. Physical model - identifies the pagination of the document, the layout of information on a page, the page number, etc
3. Property model - identifies information about the property, such as address, sellers, broker and brokerage names, legal
descriptions, etc.

With appropriate software, this datastream can be converted to another format appropriate to INTERNAL processing by a document
recipient. For example, in this following snippet, TWO names are assigned to some text content of the document. The first name says
that the text is "the english version of the legal name of the 4th signatory to the document", and the second name indicates that
the same text is "the english version of the legal name of the second owner/agent signatory to a listing of legal property for
sale".

	<en names='Document.Signatory.4.LegalName.en Property.BrokerageListing.Signatory.2.LegalName.en'
	>Seller #2 Legal Name</en>

This markup can be converted into a form that is appropriate to INTERNAL processing by a document recipient, e.g.,

	<Document.Signatory.4.LegalName.en>Seller #2 Legal Name</Document.Signatory.4.LegalName.en>
	<Property.BrokerageListing.Signatory.2.LegalName.en>Seller #2 Legal Name</Property.BrokerageListing.Signatory.2.LegalName.en>

or it could be converted into a range of alternative encodings that are appropriate to INTERNAL processing by the recipient.

The objective is to create a standard that accommodates evolving information models, without creating the need to change the
standard whenever anyone needs to augment the 'standardized' model, or wishes to create their own model. It keeps the metadata about
one's model in a single place -- a dictionary that is federated with other dictionaries -- rather than haphazardly entwined with
one's legacy markup. But most important of all, it is SIMPLE, while meeting all of our primary requirements, most specifically that
concerned with accommodating CSS styling -- a requirement in particular one yet to be satisfied by sample markup posted thus far.

My plans include adding the other 2 pages to this particular contract -- these attachments provide detailed information about the
property being listed for sale, and would be a challenge for any less open-ended encoding scheme than what is proposed here.
Thanks,
John McClure
US Contracts.com

Attachment: JMcClureListingContract.xml
Description: text/xml