Re: [legalxml-econtracts] The Future We Want?

[Jason Harrop <jharrop@speedlegal.com>]

The other consensus tentatively polled today (correctly in my view) was 
that presentation is out of scope.

That means that the XML purporting to represent the contract is just 
that - XML.  Crucially, it is a representation of the contract.  It can 
be validated against the schema to be developed by this TC to verify 
that it is in fact a contract (as understood by software ).  Its also 
the contract, as understood by the parties - see further below on this 
point.  

So, to address your alarmist contentions, you _can_ use XPath and XQuery 
on the contract.  You _can_ search for a caption.  And the caption 
numbers _can_ be hardcoded (see the example markup both you and I 
posted).  Of course you can cite a specific part of the contract.

Mentioning XSLT at this point is a red herring.

This XML purporting to represent the contract is  _the_ contract,  not 
just as understood by software, but as understood by the parties.  And 
it can be visualised and recorded for posterity however the parties 
wish.  It is that visualisation, or presentation format, which the 
parties are likely to sign.  Whatever format they choose (be it the raw 
XML, which is likely in agent-based scenarios, PDF or a printed Word 
document (both of which are likely for the foreseeable future, or CSS or 
SVG) is their choice, and will be the document referred to if the 
contract is ever seen by a court.  Again, it is not for us to dictate 
what that format is, much less decree that it can't be PDF or RTF or 
something else.  

This means there are quite probably several representations of the 
contract, but only one which was signed and is definitive.  Same as 
today, where there is often an electronic representation stored on a 
computer somewhere, which people can use when it suits them, photocopies 
provided to people who need them, and several signed counterparts. 
 Different representations, but only the signed counterparts are definitive.

Another analogy: have a look at the "Available Formats" section in 
http://www.w3.org/TR/REC-CSS2/

It says that the CSS2 specification is available in HTML, plain text, 
gzip'ed PostScript and PDF.  It goes on to say "In case of a discrepancy 
between the various forms of the specification, 
http://www.w3.org/TR/1998/REC-CSS2-19980512 
<http://www.w3.org/TR/REC-CSS2/Overview.html> is considered the 
definitive version."

What software can do with that presentation format obviously depends on 
what format the parties choose.  For this reason, you'll probably want 
to write your software against the non-presentation XML we are 
standardising.  The XML (ie as standardised by our TC) will often be all 
the parties ever use.  That is what will end up in contract management 
systems, and will be used for generating reports etc etc.  But, if there 
turns out to be a discrepancy between the XML and the thing they signed, 
then the latter is what counts.  My understanding from the teleconf 
today is that this is well understood and accepted by the lawyers in our 
midst.  Anyone care to confirm?

Obviously the risk of using the XML we are standardizing in contract 
management systems etc, where some presentation format is actually what 
was signed, is on the person using it.  No different from today.  But if 
you are really concerned about fraud, and want to check up front that 
the XML version contains the same words, it is a simple matter to do so. 
 You could open the XML version in your tool of choice, and use your 
eyes to compare it to the presentation version.  Or you could use 
software to compare the characters in the presentation format (whatever 
it is, including for example PDF) against the standardised XML, and 
report any discrepencies.  Or, you could just ask how the presentation 
format was prepared.

Hope this helps.

cheers,

Jason



John McClure wrote:

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