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)


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. 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).... so CSS is surely part of the technology
necessary to render the contract. 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 -- in any event, the XSL-T output is
normally XHTML/CSS, so you've got the same problems that you're saying you've
bitterly experienced, albeit now with an XSL-T-generated contract.

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

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'? 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.

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), 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.  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. 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).

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

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

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? Let's sidestep that whole
problem by making the final image the interchanged document, not the "pieces"
that make up the final image.

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

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

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

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