RE: [legalxml-econtracts] The CSS issue (was .. Req #106)

["John McClure" <jmcclure@hypergrove.com>]

Jason,
You've asked me to reply, so I will.

1. You ask " 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." The technical issue here is whether eContract markup will
support formatting using the so-VERY-common CSS standard. The functional issue
is the definition of what is exchanged between the parties -- is it the pieces
that can be combined programmatically into the contract artifact, or is it the
artifact, the image, its complete text?

2. You ask "No legislation anywhere in the world is going to mandate that the
output must be XML+CSS, so why accord it any special treatment?" My expectation
is that if legislation were to exist on this subject, that it would state that
the "final image" constitutes the official record of the contract, no less than
the final image. That would include PDF, RTF, XHTML, SVG, XSL-FO, flat text,
etc -- all formats that represent a final image. My proposed solution, using a
"names" attribute on the XHTML/SVG/XSL-FO elements -- is developed with exactly
that sort of legislation in mind. My proposal is true to the charter of
LegalXML -- to create standards for the transmission of legal documents using
the XML protocol. Worrying about PDF and RTF is an application-level concern,
outside the scope of LegalXML.

3. You ask "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." (1) Citations are made all the time to specific
text within a document. Specific text within documents whose presentation is
generated using XSL-T cannot be linked-to using the most basic machinery of the
Internet: the hyperlink. It's that simple. It's that realization that made me --
18+ months ago, from work in the LegalXML Citations WG -- conclude that the
proper subject of exchange between parties to a contract must be the
presentation artifact. It was on that basis that I set about to fashion a
proposal for preserving the semantic markup that we, in LegalXML, want to convey
as well with the final image -- and hence the notion of a "names" attribute on
XHTML/SVG/XSL-FO elements was born. (2) From your question. it appears you
believe that the document stored at the URL is the official record, and it is in
a presentation format.  Fine, that correlates to my basic assertion, that the
document exchanged must be a presentation document. However, you have been
arguing forceably that the document you want to be exchanged -- encoded using a
standard that we are defining -- is one that references an XSL-T stylesheet
which creates the PDF/.../XSL-FO image. You've been saying you do not want to
exchange the final image -- you want to create one on the fly -- you want to
exchange something less than the final image. Your position seems inconsistent
with our charter -- to define the standards for a contract, the official record
..... you don't appear to want to define standards for a contract, but rather you
want to define standards for something that is used to create the official
record of the contract.

Finally, you say you "can't see any justification for elevating CSS above all
these alternatives" -- suggests to the non-technical audience that this is a
matter of CSS _or_ XSLT. That is not true at all. Support for CSS does not
foreclose applying an XSL-T stylesheet to an XML formulated to accommodate CSS
stylesheets, whether done server-side or client-side, whether outputting PDF,
RTF, XHTML, SVG, XSL-FO, or something else that _your_ application requires.

John McClure