RE: [legalxml-econtracts] Legal Blob

["John McClure" <jmcclure@hypergrove.com>]

This is a response to a note I received about my last posting.. Sorry for its
length; it proposes that
(a) eContracts stop working on the structural model for a contract
(b) agree to accept the tagset for a "legal universal document"
(c) agree to accept the tagset for legal envelopes
(d) not duplicate tags already represented by (b) and (c)
(e) focus specifically on contract semantic information requirements

As an important part of this proposal, I urge the creation of an OASIS/LegalXML
Universal Document Language (UDL) TC that is focused on the gap between the
OASIS Open Office TC, the LegalXML Court Filing TC, the Universal Business
Language (UBL) TC, and the W3C presentation dialects (XHTML, SVG, XSL-FO, and
XForms).

Regards,
John

>I don't think anyone in eContracts has modified the vision of a structured
>contract document in favor of a BLOB in an envelope.

I was reinforcing the point that, if you don't name the document-structure tags
with names that lawyers know and use, then we're left with a tag called
"LegalBlob" ... my reference is to clauses not documents filed with a judicial
court or exchanged between attorneys.

In the previous May 21 call, I did raise the notion that the Document Type
element of Filing 1.0 (and, Blue) schemas could be used to distinguish between a
ContractDraft, a ContractOffer, a ContractCounterOffer, and a
ContractAgreement -- each payload of the LegalXML envelope would have its own
requirements. This approach could provide a needed clarity to our standards'
designs. Our interchange requirements would need to state that "contracts are
required to be exchanged within the LegalXML-sanctioned envelope", that is, an
envelope from which certain information about the document can be extracted.
This would incorporate and support work already done within LegalXML.

>And is this like the universal legal document discussion we had in the last
>eContract call. Is this larger than scope of eContracts?

Yes, a universal legal focument -- that's what this clause model gets to, no
less as a direct consequence of this "new" requirment to support non-contract
documents. So here is my question for the TC: would it not make the utmost
organizational sense to have the clause model defined outside of the eContracts
TC altogether, and to focus the efforts of the eContracts group on individual
semantic elements inside of the contract?

I see no need for a Universal Document Language (UDL) to redefine or duplicate
the elements already defined by the Court Filing specification, or whatever
other exchange standard a UDL group designates acceptable. Rather, the UDL is
the base DTD or Schema used for LegalXML documents located within a LegalXML
envelope. The eContracts DTD can build upon it, identifying a list of simple
character-string elements -- with no or little structure whatsoever, apparently
as Dr. Leff's scenario has done. These are the semantic data items by consensus
deemed to be critical.... why? because these are no less than the items that are
desired to be extracted from a contractual document by the parties in its
exchange, that is, this list enumerates the support necessary to the
applications envisioned by the scenarios, depending upon whether the document is
a ContractDraft, ..., or a ContractAgreement.

Using XML Namespaces, the LegalXML envelope also provides a location where
metadata about the contract can be placed, eg. the value of the contract.
Further, the envelope can be the container for other related dataitems, eg
workflow data items, negotiation data items, performance data items, and so on.

Legal envelopes must convey presentation material, with attached presentation
material, whether in XML, PDF, Word, or whatever. Given that simple FACT, a
ContractDraft that is not presentation material would be barred from being
within the payload of the envelope, meaning that the ContractDraft (again, using
XML Namespaces) would be located within the envelope's header structure. Now,
because a ContractOffer, Counter, and Agreement are all legally required to be
PRESENTATION documents, then they WOULD be able to be in the payload of the
envelope, and would equally be applicable to so called "non-presentation" XML
contracts (which DO in fact have a presentation -- because they are text, then
they can be printed out).

Now, it is possible to have a non-algorithmic CSS presentation of a
ContractDraft document, but only to the extent that the UDL accommodates
eContracts' presentation requirements. However I believe that eContracts'
presentation requirements are NOT unique with respect to any other legal
document, therefore the question of whether the ContractDraft structure is
acceptable as a ContractOffer structure is where it should be: within the domain
of those creating a UDL standard.

So I encourage those interested in establishing a UDL TC, while hoping that the
TC would investigate the claim that the Open Office TC's work is irrelevant to
their own. I am also hopeful that the UDL TC would address how to preserve one's
ability to extract semantic information from a presentation document encoded in
the OASIS Open Office XML or in one of the W3C standard presentation dialects
such as XHTML, XSL-FO, SVG, and XForms.