(g) Key use cases and assumptions

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

Jason said:

>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.