[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 <html> Thanks for the opportunity to review your requirements specification. I hope to join your call for at least a bit tomorrow. Standardized markup of legal documents is something I've thought a lot about, but not very systematically or recently. (You've probably seen the attached ancient article on the subject.) 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: <ul> <li> 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. If not, you may want to consider providing another general purpose element, perhaps called a 'chunk' or 'span.'</li> <li> Support for metadata at all levels strikes me as critical.</li> <li> It seems that you have not focussed much if at all on markup of document <u>models</u> - 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. Would need to include mechanisms for variables, conditionality, repetition, constraints. Maybe we're talking a metaschema here.</li> <li> Some benefits of XML markup that I don't think you emphasize include: search (both within and across documents), easier navigation/browsing, enablement of auto-summarization.</li> <li> I recently interviewed a couple dozen partners and associates at a major law firm about their document drafting (mostly contracts) practices and problems. Big issues are pretty much as your draft states: (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. 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 upon.</li> <li> A big motivator today for many players is <u>compliance</u> (Sarbanes Oxley, HIPPA, etc). Well structured contracts whose provisions are easily found and tracked are essential. Ditto for rule-governed, auditable contract creation and management processes.</li> <li> I'm not as pessimistic as your group about the prospects for mainstream adoption of XML-based contract drafting. WordML will familiarize users with primitive forms of markup, and I expect some legal tech players to build on that opening wedge. Client, court, and agency pressure for structured documents will add impetus. Nonetheless, I agree that dramatic benefits will need to be shown before many contract professionals change their ways.</li> <li> I'm also not sure you should fully disregard the possibility of XML contracts sometimes being the assented-to objects. 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. 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> <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> <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), 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. 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> <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> </ul> Marc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]