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)


Hi Dan

Yes, its a good idea to discuss this issue at this week's teleconf.

But the 'first take' below invites us all to answer 'yes', without 
acknowledging the price we would pay for that response.

Here is one way to put it which does require us to acknowledge there is 
a price to pay:

"ALWAYS or NOT NECESSARILY: In our schema design, where choosing between 
representations which are convenient for CSS on the one hand, and 
representations which are attractive owing to other considerations (eg 
ease of use, economy of expression, validation), CSS concerns will 
ALWAYS or will NOT NECESSARILY trump all other considerations."

Here is an alternative, which articulates what we are asking (fairly or 
unfairly) of CSS:

"Yes or No: Irrespective of any other consideration (eg ease of use, 
economy of expression, validation), our schema must be such that when an 
appropriate CSS is directly applied to a XML document (valid according 
to the schema), the output will be of a quality that could be printed 
and signed."

I think there are still a few more issues to tease out on the mailing 
list in order to ensure a productive fully informed teleconf.

To this end, I invite John McClure (following Dan's "Benchmark 
Contracts" email) to mark up section 6.4 (just (a) to (d) would be 
sufficient) of the lease document at http://contracts.corporate.findlaw.com
/agreements/goldman/hanover.lease.1997.08.22.html
using his XML, and to provide CSS which when applied to the XML presents 
it as closely as CSS is capable of to that web page.  Note that each of 
paragraphs (a), (b), (c), (d) have headings which appear inline.

I will also mark up those clauses using the labels which were agreed in 
the last teleconf, and the content model for those labels i have been 
advocating.

cheers,

Jason

Daniel Greenwood wrote:

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




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