[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: The Future We Want?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]