The CSS issue (was .. Req #106)

[Jason Harrop <jharrop@speedlegal.com>]

For what it is worth, here is my take on the CSS issue.

1. Background - CSS can be applied to an XML document to give you a 
human readable view of it in some versions of Internet Explorer, Mozilla 
(and Netscape).

2. But browser support prior to version 6 of IE (and Netscape for that 
matter) both for CSS itself and its application to XML (ie not just 
HTML) is poor (bitter experience).

3. Without the hard-to-achieve combination of a document type designed 
around the needs of CSS, an appropriate CSS stylesheet, and a browser or 
other tool which properly implements all the relevant parts of CSS, you 
can't expect output of a quality that you can print and sign.

4. For this and other reasons, for the foreseeable future, the contracts 
people sign will be in PDF or Word/RTF format.  You get this format by 
transforming the XML using XSL/XSLT.

I acknowledge you can also get printable PDF from XML + CSS using 
yeslogic's Prince or a similar tool.

5. The quality necessary for a document you can sign is easily achieved, 
owing to the flexibility of XSL/XSLT. It doesn't place any particular 
demands on the XML in the contract.  And you can render the contract in 
html in a way any version 4 or later web browser can display (in fact my 
company currently does this, and we create a CSS stylesheet as part of 
the process).

6. It pays to read your PDF or Word document before you sign it (the 
"faudulent mischief" point).

7. If you are looking to the future, and want to sign an XML contract 
electronically, you will still need to read the contract.

8. In the electronic signature scenario, you will read the contract in a 
tool of your choice.  You might be comfortable looking at it using CSS 
in your web browser (how do you sign it there?); it is more likely that 
you'll be using some XML Contract aware tool (eg a contract management 
system), which might use CSS to display the document for you, but is 
more likely to use other techniques. For example, cross references and 
definitions can't be enabled as hyperlinks until you've transformed them 
in to hyperlinks.

9.  The argument that CSS guards against fraud is dangerous.  It does 
nothing to stop me putting an attribute somewhere like:

	status="Parties agree this clause will not be enforced".

If i sign a document and it has that attribute in it, you are never 
going to know if you just look at the document using CSS.  To guard 
against this, validation is a good defense (but the web browser won't 
require this); XML contract aware tools are even better!

10. So, like most other XML document types, we should be happy modelling 
our content in a way which models it accurately, and be happy with the 
CSS support which falls out of it.  To shape the model of the contract 
around the requirements of CSS would be unfortunate.

Please also see a couple of notes in line below..

cheers,

Jason



John McClure wrote:
:

> I also MUST put onto the agenda for the next telecon the following, urgent,
> question:
> 
> In Requirement #106 from Jason Harrop, is the "stylesheet" there referenced
> referring to an XSL stylesheet OR a CSS stylesheet? The requirement now reads:
> "106. Formatting to be handled via a stylesheet, which typically will apply to a
> class of documents. The document author must NOT (emphasis added) be able to
> change the formatting (ie override firm style) by applying formatting directly
> to a clause."

Not worth emphasising really - all this is saying is that there is not 
need for our document model to allow attributes on a clause or whatever 
whichs let you set the margin, para spacing etc.  That is a job for the 
stylesheet.

> 
> The importance of this question is that, if CSS is a recognized stylesheet
> language, then there are at least three extremely important consequences. The
> standard contract datastream must therefore:
> 1. contain elements that correspond to every string of text shown in the
> contract
> 2. contain elements that are reasonably in the same order as their order of
> presentation
> 3. contain elements that facilitate the proper formatting of the contract

I think these reasonable sounding requirements have a pointy end to 
them, which manifests itself in your <en> tag?

> I also would add that all elements should allow class and style attributes to be
> specified, which directly contradicts Requirement #106. 

Actually those attributes would be fine, since what they mean would be 
defined in the firm style.  The issue with those attributes is just what 
the values can be - does the document type define the possible values 
exhaustively, or is it CDATA... a question for another time.

> I am very concerned that
> this requirement to prevent modification of presentation styling is much more an
> application-level requirement, not an interchange requirement. I also add that
> CSS is an extremely important W3C standard, not one built just for HTML.... it
> was built for direct display of XML datastreams, and for display of XHTML
> datastreams created by XSL-T stylesheets.
> 
> Personally, I am resolutely in favor of supporting CSS -- in the manner of the
> consequential requirements I outline above -- but there are other reasons beyond
> a simple declaration of support for the W3C's long-established CSS standard, the
> most important of which is that the opportunity for fraudulent mischief is too
> great with contracts that are generated by programmatic application of an XSL
> stylesheet to an XML datastream. 

See 6, 8 and 9 above.

> I simply do not want to be party to a standard
> that allows contract clauses to be included/excluded, or their text to be
> determined, programmatically. 
> My objective is to minimize absolutely the
> probability of repudiation of a contract encoded in conformance with the
> standards that we are developing.
> 
> If the workgroup decides that CSS support -- with the consequences outlined --
> is critical, then I propose that Req #106 be worded as follows:
> 
> "106. All contract datastreams defined by this workgroup shall be able to be
> formatted for direct display using the Cascading Stylesheet (CSS) language, as
> defined by the W3C. No contract datastream may assume text that is or may be
> generated programmatically prior to its presentation for signature using digital
> procedures (in contrast to printed contracts). No contract datastream may assume
> an order of XML elements that varies from the normal order of presentation of
> those elements. No contract datastream may assume that content such as headers
> and footers will be replicated during the display of the contract."
> 
> I urge us to create a standard that represents the entire contract, not much
> more, and most certainly NOT ONE IOTA LESS. 
> I urge us to resist creating a
> standard for a datastream from which the contract is DERIVED using programming
> tools like an XSL-T engine. If we create a standard from which the contract is
> derived, then it's clear to me that we are not defining a standard for the
> contract itself.

What happens to all the non-structural information we are busily 
identifying in our scenarios?  Does it stay in the contract which is 
signed?  If so, do you see it using CSS?  If not, how do you get rid of 
it? Using XSLT?


> This issue is of critical importance to me, personally, 

Perhaps you could explain why you need CSS so much. I ask this 
sincerely, since maybe I will to for some need I am yet to encounter...

> for it is the one I
> raised forcefully during our "chartering" and it was one that was deferred until
> this "requirements phase" we're deeply within. This decision is necessary now
> because other discussions, such as whether the standard will allow caption
> numbers to be generated by the recipient of a contract that is coded in
> conformance to the standard, depend in large part on its outcome.

The ability to autonumber and auto-crossreference is a clear 
requirement.  Without it, our standard will not be used to create 
contracts which are longer than a few pages.  And XML has its greatest 
potential with long contracts (like the real estate one you referred me 
to at http://contracts.corporate.findlaw.com
/agreements/goldman/hanover.lease.1997.08.22.html ).


> I urge this group to require direct formatting by CSS of the xml datastream we
> call an eContract.
> John McClure
> 
>