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 CSS issue (was .. Req #106)


I'm glad Jason has offered up this view and I for one agree.

We run the danger of designing the end user application and closing the door
on future alternatives if we trap ourselves with CSS. 

CCS has its place but the structure of the data "standard" should be our key
concern.

-----Original Message-----
From: Jason Harrop [mailto:jharrop@speedlegal.com] 
Sent: Saturday, April 19, 2003 2:14 AM
To: legalxml-econtracts@lists.oasis-open.org
Subject: Re: [legalxml-econtracts] The CSS issue (was .. Req #106)


John and other TC members

I'm afraid i do need to reply briefly, since this seems to be an 
important discussion.  

There is one important difference between the XML+CSS approach on the 
one hand, and the XSLT enabled approach on the other, which your reply 
overlooked.

The difference is that with a pure XML+CSS approach, you rely absolutely 
on browser support.

When I say XSLT is more flexible, that's because the server can do the 
transformation, overcoming and compensating for lack of standards 
support at the browser end.  

I think that when it comes to formatting there are 2 major scenarios:

1.  People use a standards based rendering technology of their own 
choice (eg XHTML/CSS, XSL-FO etc), or a non-standards based one (eg PDF, 
RTF etc)

2.  People use a tool which understands our contracts format using 
proprietary technologies (ie a contract creation or management system 
which uses DOM or SAX or whatever to provide enhanced contract 
visualisation).

People will sign a document formatted using whichever of the formatting 
technologies noted in 1 above suits them.

I can't see any justification for elevating CSS above all these 
alternatives, and insisting that our XML must be such as to directly 
support it.  What is so difficult about transforming where necessary to 
perfect for CSS support?  It is taken for granted that this will be 
necessary with the other formats.

Please see below for more..

cheers,

Jason


John McClure wrote:

>Jason,
>I am responding to your remarks; I can't imagine saying much more than 
>this prior to the next conference call, so you can have the last word 
>if you want! Thanks, John
>
>  
>
>>-----Original Message-----
>>From: Jason Harrop [mailto:jharrop@speedlegal.com]
>>Sent: Thursday, April 17, 2003 4:33 PM
>>To: legalxml-econtracts@lists.oasis-open.org
>>Subject: [legalxml-econtracts] The CSS issue (was .. Req #106)
>>
>>
>>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).
>>    
>>
>
>Please be fair: the same slight-with-regard-to-some-browser-versions 
>can be said of XSL-T also.
>
Only if you rely on the browser to do the XSLT.  Today you probably 
wouldn't - you'd do it server side.

>By way of more background -- note that USUALLY when one applies an 
>XSL-T stylesheet to an XML stream, that it is XHTML/CSS stream that is 
>output (and displayed by the browser)....
>
Well, sometimes it is XHTML/CSS.  But most often, its to get RTF or PDF, 
which you'll find most end user insist on.

> so CSS is surely part of the technology
>necessary to render the contract.
>
Sure, it can be.  As I note below, my company does use it strategically 
(but in building our own contracts schema, we stopped short of basing 
our design decisions on their implications for CSS, and with no regrets 
so far...)

>The question though is whether CSS technology
>is to be a factor in our standards definition or not -- I have 
>enumerated the consequences I know of to-date from this decision.
>
>  
>
>>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).
>>    
>>
>
>Please be fair: the XSL-T engine in versions prior to IE 6 wasn't worth 
>spit -- XSL stylesheets for 6 don't work for IE 5 -- different syntax! 
>I'm not very familiar with the XSL-T engine in Mozilla --
>
Again, see above - XSLT can be done server-side, so limitations in 
client side CSS are irrelevent.  The same can't be said for CSS, unless 
you also use server-side CSS, in which case you no longer need to insist 
our standard directly supports CSS!

>in any event, the XSL-T output is
>normally XHTML/CSS,
>
As i said, sometimes it is; more often it is RTF, or PDF.

>so you've got the same problems that you're saying you've bitterly 
>experienced, albeit now with an XSL-T-generated contract.
>  
>
Not so.

>  
>
>>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.
>>    
>>
>
>I can create XHTML/CSS and XML/CSS contracts quite nicely, and I have 
>published strawmen to prove so.
>
I can do alright myself, with a v6 browser, but in testing to date, 
we've had to bastardise the XML to make CSS like it, and we still 
haven't been able to achieve the perfect output we get in XHTML, PDF and 
RTF via transformations.

>I also point to the many shrinkwrap licenses that are on
>the web -- that's the pet project of Leff and Greenwood I believe, or 
>at least it was.
>  
>
I guess a lot of them use CSS, but they tend to illustrate my point: 
they are simple contracts with simple formatting requirements.

>But again, if you're using XSL-T, and you're outputting XHTML/CSS with 
>the XSL-T stylesheet, why are you not equally concerned about 'getting 
>all the parts to work together'?
>
See above for the server-side answer again...

>If you're suggesting that you'd like to see us standardize on a W3C 
>rendering technology other than XHTML/CSS, eg XSL-FO or SVG, because 
>you find XHTML/CSS so problematic, that would be interesting to 
>discuss, because you would be much closer to my thinking than I 
>realized before -- it's just that I think that XHTML/CSS should not be 
>excluded from the "troika" of acceptable renderings because it IS in 
>such widespread use, and there ARE many applications in which it works 
>just fine.
>  
>
I think that when it comes to formatting there are 2 major scenarios:

1.  People use a standards based rendering technology of their own 
choice (eg XHTML/CSS, XSL-FO etc), or a non-standards based one (eg PDF, 
RTF etc), and they be prepared to use XSLT if necessary to get there

2.  People use a tool which understands our contracts format using 
proprietary technologies

I can't see any justification for elevating CSS above all these 
alternatives, saying our XML must be such as to directly support it. 
 What is so difficult about transforming where necessary to perfect for 
CSS support?  It is taken for granted that this will be necessary with 
the other formats.

>As you may recall, I have demonstrated many times a method for marking 
>up all three types of datastreams (XHTML, XSL-FO, and SVG) with a 
>"names" attribute on the elements whose value corresponds to the markup 
>in a LegalXML datastream, eg
>
><span lgl:names='Contract.TerminationDate.en'>November 1st, 2002</span>
>
>>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.
>>    
>>
>
>Thanks for noting Prince. You can also get page-printable contracts 
>using XSL-FO (which can be converted into PDF),
>
Yes, that's the most common way to get PDF (and how my company does it - 
server side of course!).

>and SVG (which also can be converted into
>PDF). XSL-T stylesheets can output XSL-FO and SVG datastreams just like 
>it can XHTML. And, of course, anyone can output PDF directly from a 
>browser that is displaying HTML or XHTML if Adobe is installed as a 
>print driver ....
>
>
>  
>
>>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.
>>
My sentence above is the important point here...

>>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).
>>    
>>
>
>Of course you do... you're outputting XHTML, right? And it uses CSS, 
>right? Why don't we just skip the XHTML output, and format the LegalXML 
>contract directly -- that's what CSS is for.
>
Because to be sure you can go straight to CSS you need to place 
constraints on what XML you use to represent the contract - that's the 
reason for this conversation, right ;)?  - and you need to be sure the 
end users have a tool which supports CSS properly (ie a v6 browser).  

>If you don't want to be constrained to CSS
>rendering, then let's also accept SVG and XSL-FO, and annotate their 
>elements with the "names" attribute? I would support that very fast.
>
>  
>
>>6. It pays to read your PDF or Word document before you sign it (the 
>>"faudulent mischief" point).
>>    
>>
>
>This does not address the "mischief" point.... which is about 
>reproducing at a later time the contract that was signed.
>
>It's just common-sense that the final
>image read and agreed-to is what must constitute the written record of 
>the contract..... you know that it's possible to write XSL-T code that 
>will yield date-specific output, or that will access another site for 
>parameters to drive the software (specifically, see the document() 
>function in XSL-T).
>
I think we both agree that you can transform our XML to something+CSS 
(where 'something' is the same or different XML , or XHTML), and sign 
that (subject to the concern noted in 9 below).  But the final image 
could just as easily be PDF or something else.

>>7. If you are looking to the future, and want to sign an XML contract 
>>electronically, you will still need to read the contract.
>>    
>>
>
>Yes, but that does not address the concern of reproduceability at a 
>later time, as in a court.
>
I maintain that any of the alternative output formats will do for these 
purposes - whichever the parties chose to sign. No different from today, 
where the output format could be PDF say.

No legislation anywhere in the world is going to mandate that the output 
must be XML+CSS, so why accord it any special treatment?

>>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.
>>    
>>
>
>I suspect that soon rudimentary digital signature technology will be 
>built into one's browser, which will gather together all the resources 
>used to create the rendered image. It will look into the HTTP header 
>for resource pointers; it will look into the xml-stylesheet programming 
>instruction for the stylesheet object, and it will look into the html 
>file itself for links to image objects. I will be pleasantly surprised 
>if it looks into an XSL-T stylesheet to identify all the resources 
>referenced therefrom, including CSS stylesheets and image objects. I 
>would be very surprised if the process supported downloading the 
>codebase for <object> elements referenced by the HTML page or the XHTML 
>page created by the XSL-T stylesheet, or for downloading the resources
specified by an XSL
>document() function within the XSL-T stylesheet. Oh, and all entity
references
>of course will already have been resolved by the browser, and I suppose
that
>secondary CSS stylesheets will also be pulled down. And of course
non-standard
>stuff like data-binding won't be supported. And so on.
>  
>
I'm not sure what you are getting at here - it all seems to support my 
point that you need to do your stuff server side and deliver properly 
formatted documents to the client using their preferred lowest common 
denominator format (PDF, RTF, or maybe XHTML/CSS).

>But I also would like to address this issue of resolution of links, 
>because it leads to my most damning assertion about XSL-T generated 
>contracts --- I have found absolutely NO WAY to link to XSL-T output, 
>one can ONLY link to XML or HTML elements (or datafiles), from another 
>file.... do we really want to create a world in which you can't link to 
>the 3rd paragraph of Section 2 in Article 3 from somewhere else, should 
>that be generated content?
>  
>
Can you please clarify what you are talking about here?  I would say 
(simple-mindedly perhaps) that either a contract is stored at a URL from 
which it can be later retrieved, or it isn't.  If it is stored at a URL, 
then how it got to be there is irrelevant, but it could be XSLT output 
just as as it could come from any other process.

>Let's sidestep that whole
>problem by making the final image the interchanged document, not the 
>"pieces" that make up the final image.
>
Just to be clear, I have no probs (once parties have finished their 
negotiations, in which it may be more convenient to exchange raw XML) 
with them signing a "final image".  

All i say is that there is no reason to assume that image will be 
XML/CSS.  Look at what people do today, and start thinking PDF or RTF. 
 People are comfortable and familiar with  tools which support these 
formats, and an XML format which fits in with these is what will "get 
off the ground".

>
>  
>
>>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!
>>    
>>
>
>The technical point of the proposed CSS orientation is that only data 
>that is in the content of XML elements is available to be formatted. 
>CSS will NOT format data that is located in an attribute. And since it 
>is not formatted, then it is not visible. If it is not visible, then no 
>parties can or have agreed to it.
>
Still, I would be most uncomfortable having

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

sitting in the XML file which contains any contract I had just signed, 
whether visible or not!!

>Validation is not the issue here -- it is that there must be **** a 
>physical record of what was agreed to ****. When a contract is 
>"generated", then there is NO physical record until and unless it is 
>printed (and that doesn't sound like an eContract to me).
>
?

>
>  
>
>>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.
>>    
>>
>
>I assert that there is very much the need. I cannot expect an XSL-T 
>stylesheet to know a-priori what strings are centered on a line, where 
>line breaks are to occur, what individual words are to be bold or 
>italic, and so on.
>
Not true.  We do that quite happily with contracts today.  

And so do many other organisations, with all sorts of documents.  Have a 
look at a tool like Cocoon.

>That would be
>too much of a job for the stylesheet.... unless of course you want a 
>per-contract stylesheet, which I find a horrible thought for many 
>social, financial, and technical reasons.
>
There is no need for one stylesheet per contract.  Our customers have 
one stylesheet fullstop.  Once its created, they can forget about it. 
 The best thing is that it can be created largely automatically, so it 
really isn't a problem.

>
>  
>
>>>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?
>>    
>>
>
>Yes, the <en> element is part of the solution that I propose.
>
>
><Clause class='DoubleSpaced'>
>   <Caption>
>        <en>Response to <en class='bold'>three</en> consequences</en>
>   </Caption>
>   <Paragraph>
>        <en>I think these reasonable sounding requirements have
>           a pointy end to them, which manifests itself in your
>           &lt;<text style="font-style:italic'>en</text>&gt; tag?
>        </en>
>   </Paragraph>
></Clause>
>
>  
>
>>>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.
>>    
>>
>
>If style attributes are allowed, which you seem to say is ok, then ipso 
>facto the firm's style is being overridden.
>
No, the firm's stylesheet would match on those.  If there is no match, 
the attribute would be ignored.

>I've never seen a DTD define values for
>class or style attributes -- in fact, it's near impossible to do so 
>given that each may have multiple values (so let's not raise that 
>question).
>
And if they aren't constrained, there is little chance the stylesheet 
will match it (unless our lawyer or contract manager edited the 
stylesheet themselves, which 99.9% wouldn't).

>
>  
>
>>>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?
>>    
>>
>
>I proposed on the list as a followup to our telecon, in February I 
>think, that we have a separate document (a "Policy" document) that 
>contains all the meta-data that we've talked about to-date -- surely 
>the idea can be refined, for instance, having two documents, one for 
>policies and one for workflow. I see no reason for metadata to be 
>considered part of the formal contract between the parties -- I 
>wouldn't mind a pointer to this metadata document (or documents) 
>located in an <html:metadata> element or some similar mechanism....
>
We can discuss this later. Of course, the details are only a problem if 
you care about using CSS directly ;) - since then you absolutely must 
keep this stuff out of the contract XML document itself.

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




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