OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [legalxml-econtracts] The Future We Want?


Jason,
I wish I were just an alarmist, but I am being factual. You say that one "_can_
use XPath and XQuery" is true only as it applies to a PIECE of the contract --
one cannot use XPATH to link to a virtual image created by applying the XSLT
stylesheet referenced by the XML stream; other PIECES of the contract can be
located in that XSLT stylesheet, a fact whose consequences have yet to be
addressed by anyone in this TC.

You also say "if there turns out to be a discrepancy between the XML and the
thing they signed, then the latter is what counts" -- is my contention, that the
XML that this TC is defining is NOT the definitive contract, so the TC should
either (a) stop calling the XML a "contract" and call it, instead, a
"negotiating document" or (b) address the issue = standardize what sort of XML
*can* be called a "contract" -- which I believe is either an XHTML, SVG, or
XSL-FO datastream, or one conforming to the eContracts schema, displayed using a
CSS stylesheet.

Maybe a different result would have obtained if the polling question had been
"do we want a spec that allows mutable contract content".... Look, I am not
saying that XSLT is not an extremely important part of any contract application.
The question is whether a TRANSFORMING stylesheet is to be allowed to be
referenced by a contract datastream following its exchange from offerer to
offeree.

XSLT is not a "red herring" -- it is the elephant in the living room.

John McClure



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]