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

["Sergio Maldonado Elvira" <sergio@smaldonado.com>]

Dear all,


My answer to that question is YES.

However, I would believe the following statement to be closer to what I
would expect this TC to get at:

"The eContracts spec shall define an exchange standard (XML Schema or DTD)
for legal contracts that, insofar as the very nature of a contract allows
it, does not interfere with the presentation of such contracts, whatever the
means used for such presentation".

In other words, despite accepting that we are inevitably describing a
certain amount of format, I believe we should make it clear that the CSS and
XSL-FO (and XSLT) standards are already meant to smoothly integrate with XML
data and such XML data (when valid against a vocabulary that follows the
Schema or DTD specs) should not do any additional effort to accommodate to
them, since that should have already been taken care of by the very
definition of Schemas, DTDs and the various stylesheets specs.



I believe we keep on facing the same problem over and over, which is why I
find it great that we try to do away with it all at once: Unlike most
real-world instances of yet "unstructured" data, the terms of a legal
contract are painfully tied to their disposition on a physical sheet of
paper and even the way they are expressed in human-readable language.

It is for that very reason that we have agreed that a stand-alone
information model would not suffice to describe most legal contracts in a
flexible way (eg. <jurisdiction>Berlin</jurisdiction>), and I understand it
is for that reason that we are striking a balance between such model and a
structural/clause model where the particular "articles" ("clauses",
"terms"...) can be divided in paragraphs, subparagraphs and so on,
themselves containing the natural language that all contracts are made of,
unless automatically negotiated between two systems.

Bearing all that in mind, we must conclude we are already describing, to a
certain extent, format. So I agree to your statement, including what I
consider the most controversial part of it: "that includes the information
needed to create conclusive presentation of the contract as agreed by the
parties".

If this makes any sense.



Regards,


Sergio

-----Mensaje original-----
De: Daniel Greenwood [mailto:dang@mit.edu]
Enviado el: 19 April 2003 23:28
Para: legalxml-econtracts@lists.oasis-open.org
Asunto: RE: [legalxml-econtracts] The CSS issue (was .. Req #106)


Hi all,

I think, based on the attention paid to the presentation issue on our
list, that we as a TC should formally address the question as part of
our requirements phase.  I suggest that we consider at least starting
this discussion as an agenda item during our next teleconference on
Wed.  I further suggest that we'll be more productive by carefully
articulating the question to be addressed - i.e. the requirement
statement itself.  To that end, I have talked with John McClure today
and derived the following draft statement that I think will help us to
clarify the issue before us.  Here is my first take at the question,
please feel free to hack away at it.

"Yes or No: The eContracts spec shall define an exchange standard (XML
Schema or DTD) that includes the information needed to create
conclusive presentation of the contract as agreed by the parties,
without the need for an intervening transformation via XSL-T or
similar process."

I think we should first agree on the question presented and then we
should determine as a group whether the answer is yes or no.

Best regards,
Dan Greenwood

==============================================
|  Daniel J. Greenwood, Esq.
|  Director, E-Commerce Architecture Program
|  MIT School of Architecture and Planning
|  77 Massachusetts Avenue, Room 7-231
|  Cambridge, MA 02139
|     http://ecitizen.mit.edu
|     or http://www.civics.com
|     dang@mit.edu
==============================================

-----Original Message-----
From: John McClure [mailto:jmcclure@hypergrove.com]
Sent: Saturday, April 19, 2003 3:11 PM
To: legalxml-econtracts@lists.oasis-open.org
Subject: RE: [legalxml-econtracts] The CSS issue (was .. Req #106)

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