OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: File Transmission @@2543

Forwarded to the Committee by Mr. Marc Lauritsen

Thanks for the opportunity to review your requirements specification.&nbsp;
I hope to join your call for at least a bit tomorrow.&nbsp; Standardized
markup of legal documents is something I've thought a lot about, but not
very systematically or recently.&nbsp; (You've probably seen the attached
ancient article on the subject.)&nbsp; I deal implicitly with lots of these
issues in our document automation work, and have stacks of notes and materials
somewhere that I regrettably don't have time to dig out.
<p>Here are some random comments in the meantime that you can share with
the committee:
I assume and hope that your model will allow 'clauses' to be declared down
to the minimal level of granularity (i.e., even a single character or symbol)
and be nested to arbitrary depth.&nbsp; If not, you may want to consider
providing another general purpose element, perhaps called a 'chunk' or

Support for metadata at all levels strikes me as critical.</li>

It seems that you have not focussed much if at all on markup of document
- i.e., masters or templates. Support for such things is likely outside
your scope, but would be highly useful, e.g. for platform-independent expressions.&nbsp;
Would need to include mechanisms for variables, conditionality, repetition,
constraints.&nbsp; Maybe we're talking a metaschema here.</li>

Some benefits of XML markup that I don't think you emphasize include:&nbsp;
search (both within and across documents), easier navigation/browsing,
enablement of auto-summarization.</li>

I recently interviewed a couple dozen partners and associates at a major
law firm about their document drafting (mostly contracts) practices and
problems.&nbsp; Big issues are pretty much as your draft states:&nbsp;
(1) frustrations in dealing with word processing mechanics, especially
when drafts circulate among firms with clashing style regimes, (2) difficulties
in finding suitable precedent material at a decent level of specificity.&nbsp;
Lots of interest in intelligent templates that embed commentary and options
in context, and let the user decide how much if any automation to draw

A big motivator today for many players is <u>compliance</u> (Sarbanes Oxley,
HIPPA, etc).&nbsp; Well structured contracts whose provisions are easily
found and tracked are essential.&nbsp; Ditto for rule-governed, auditable
contract creation and management processes.</li>

I'm not as pessimistic as your group about the prospects for mainstream
adoption of XML-based contract drafting.&nbsp; WordML will familiarize
users with primitive forms of markup, and I expect some legal tech players
to build on that opening wedge.&nbsp; Client, court, and agency pressure
for structured documents will add impetus.&nbsp; Nonetheless, I agree that
dramatic benefits will need to be shown before many contract professionals
change their ways.</li>

I'm also not sure you should fully disregard the possibility of XML contracts
sometimes being the assented-to objects.&nbsp; Businesses may find it particularly
attractive to finalize dealings in that format, with an XML version being
electronically signed, either as the original or as an agreed representation
of a physical document.&nbsp; You can imagine courts insisting on litigants
stipulating to such a thing in a contract dispute, or at least narrowing
disagreement to specific elements.</li>

I agree about the prematurity of deontic markup specification, although
you may want to consider at least providing a placeholder for formalizations
of content alongside natural language components.</li>

Maybe these are just aspects of metadata, but I'd encourage you to think
about supporting <u>levels of contracting authority</u> (who can change
the master in what ways without authorization), the various <u>document
revision</u> states (added/deleted/revised, when, by who),&nbsp; and the
tagging of provisions in terms of their <u>modality</u> or speech act type
(i.e., obligation, prohibition, warrant, representation, definition) and
the corresponding obligor/obligee etc.&nbsp; The latter would enable people,
e.g., to quick render a summary of a contract that enumerates all the things
they've agreed to do or not to do.</li>

Besides getting contract management vendors involved, you should consider
inviting comment from other document assembly engine vendors (like Business
Integrity, Ixio, GhostFill, HotDocs), document management vendors (like
Hummingbird, Interwoven, and Documentum) and "document change management"
vendors (like Litera, DeltaView, and WordSensa).</li>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]