The Future We Want?

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

To the eContracts Technical Committee:

I am concerned about the future that your specification for "legal contracts" is
intended to foster. I understand that the consensus tentatively polled today
will allow an XML datastream purporting to represent a "legal contract" to
contain an <?xml-stylesheet> programming instruction that references an XSL-T
stylesheet. This means that there is no technical provision for stopping a
stylesheet from, for example, conditionally inserting boilerplate text that is
not in the "legal contract" datastream.

Do you REALLY want these consequences?

1. No XPATH Support = no XQuery support?
There will be no single XML datastream that represents the contract as SEEN BY
SOFTWARE. There will be no complete XML datastream that one can search using
XPATH expressions because boilerplate content is being (often, conditionally)
inserted by the stylesheet. No XPath expressions written to search for a
specific caption number, for instance, will ever be possible because caption
numbers are envisioned to be generated by the XSLT- stylesheet referenced by the
XML programming instruction.

2. No XPATH Support = No Hyperlinks = No Citations?
There will be no single XML datastream that represents the contract as SEEN BY
THE PARTIES. There is no way to hyperlink to the actual presentation of any of
(a) specific structural elements such as an "Article" or specific "legal"
elements to be designed (b) specific presentation elements such as "Page 2, Line
2" or (c) any of the boilerplate content inserted by the stylesheet referenced
by the Programming Instruction.

3. No Physical Contract Datastream = Opportunity for Fraud?
There will be no single XML datastream that represents the contract as later
SEEN BY A COURT. The contract's presentation is re-created each time from
resources spread potentially all across the web; it is easy for the contract to
contain different content at different times. XML Digital Signatures technology
is not an adequate solution because it will not package resources referenced by
the XSL-T stylesheet. If the contract cannot be (re-)created because, for
instance, the resources referenced by the XSL-T stylesheet are no longer
available, then that sounds like a contract that is easily repudiable.

I believe these are serious substantive problems with the architecture that have
not yet been adequately addressed by its supporters. If the TC believes that #1
and #2 are technically possible with the envisioned architecture, then I
challenge its supporters to demonstrate this fact, or at least to cite some W3C
standard that would provide for these two items, and discuss how it would be
applied. If the TC believes #3 is not a technical issue, then I challenge its
supporters to demonstrate how an XSL-T stylesheet can be prevented from
accessing external resources by calling the XSL-T document() function.

I have proposed an architecture in which the TC standardizes two datastreams --
one for the contract itself, and one for all the workflow and other information
that everyone wants to exchange during contract formation. The "workflow"
datastream certainly can contain instructions for generating the contract
datastream, including an XSL-T stylesheet that is to be applied to the
"workflow" datastream itself -- to generate the contract datastream. In the
architecture I propose, the contract datastream would contain markup relating to
all the structural and legal data elements. and markup relating to the physical
layout of the contract -- it is an architecture that not only addresses items #1
and #2, but also directly forecloses a glaring opportunity for contract
repudiation.

Without question, the eContracts TC is presently defining a standard for a
"workflow" document, not for a "legal contract" document. Simply said, a legal
document is not mutable -- however this TC is purposefully defining a mutable
document for, allegedly, benign formatting purposes.

John McClure
Hypergrove Engineering