[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] The Future We Want?
Dear TC members, In my earlier posting on requirements I seem to have covered some ground that was resolved in your phone meeting earlier (presentation, in particular). Unfortunatly, because I have not been actively involved I did not know the meeting date and time and did not recieve the details until too late. I think the details were only sent out a few hours before the meeting which was in the wee hours down under. Please ignore aspects of my message that are negated by earlier decisions. Peter Meyer > > 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 > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]