|Subject:||(g) Key use cases and assumptions|
|From:||John McClure (jmcc...@hypergrove.com)|
|Date:||Jul 18, 2004 4:21:49 pm|
If you'd like to copy/paste your sections (g) and (h) from your "long" memo (or something based on them) to the list, i will respond.
Section attached, as you requested. John
(g) Key use cases and assumptions
A key issue dividing the subcommittee is what is the key use case for which we're designing a set of elements? For me, it is very simple: one party sends an XML file over email to another party. That party prints the document twice, signs it, and returns both copies to the sender by post. The originating party signs both copies, and sends one copy back to the second party.
This is unquestionably true document EXCHANGE. If we can't accomplish this level of functionality, I do think we've failed to create a standard for the exchange of legal documents in today's world. Certainly in the future, the digitally signed stream will be returned by email not by post, but there will always be the desire to print out and file that paper document -- to ignore that reality would be gravely stupid.
The key use case for J&P seems to be the ENTRY of the document into some software program -- hence their constant focus on the "user experience" when that program happens to be a schema-driven software application. But I've got to ask: what percentage of stakeholders truly plan to enter a contract using a raw markup editor? I have no numbers, but the idea of it to an economist such as myself is patently absurd -- that tool would not maximize the efficiency of the parties to the contract. Rather those persons would be more productive using a tool that assembled the contract for them to the extent possible (from templates and clause libraries for instance), and which then enabled them to add, modify, or strike content from the assembled base document.
In my opinion, there is no contest here -- we achieve maximum success by a standard that caters to the greatest majority of anticipated use. Let's stop kidding ourselves -- most working attorneys don't want to screw around with markup.... certainly not while they're composing contract language. They want a sofware application that handles the markup for them, that has a clause library, and so on.
So, I believe that the key use case concerns document assembly and printing. not the entry of XML markup to an XML markup editor. So it is SOFTWARE AUTHORS who need to understand our standard in depth, for they are writing the code that produces the markup mandated by our standard. Over time, when one considers the many elements needed for semantics, then markup editors become even less practical.
How does the key use case relate to our standards development? First, it provides a wide opening for unverifiable assertions about the "ease of use" of one markup alternative over another. Second, it ultimately determines what elements are included in the standard -- under my key use, enabling the contract to be printed, then the key elements are ones to transmit layout constructs, such as headers footers and positioned content. If the focus is merely on entering the contract to a raw markup editor, then there is not much need for such "after-the-fact" composition, since it is envisioned to be outside the scope of our standard, more in the province of document assembly software that "adds headers and footers and cover pages and tables of contents" I was told once the attorney has crafted the language. But, it's pretty clear that WYSIWYG displays (what you see...) form the baseline for word processors -- today used by 100% of law firms. It just seems to me that a standard that is unduly focused on the needs of a small number of non-WYSWYG attorneys is going to cause problems for its long term success.
My point is this. I come from a technician's perspective -- 30 years worth, from the days of UNIVAC and 029 card punch machines. As an architect. I demand technical justifications support technical designs, such as an XML markup dialect is. Key use cases centered on the "user experience" while performing, essentially, text entry for a contract , ultimately has meant that technical merits of one approach are prone to being jaw-droppingly trumped by claims about someone who isn't really a particularly typical user at all.
The ease of use during text entry using a schema-driven editor is totally dependent on the way that application was programmed. In the <area> discussion, the argument is about element names vs element attributes. Utlimately, there's going to be 2 lists that such a user would have -- one of names, and one of attributes -- that's not going away, and is pretty central to the very definition of a schema-driven editor, i.e., software that exposes a schema directly to an end-user.