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

["Chambers, Rolly" <rlchambers@smithcurrie.com>]

I apologize in advance for the length of this message. I agree with
addressing the presentation issue. To me the issue is more whether the
XML representation of a contract or the presentation image of it will be
intended by the parties as the binding expression of their mutual
agreement and thus will be enforced by the courts as a legal matter
(i.e. will be "conclusive").
 
In common law (US, UK, AU, Canada, and related jurisidictions), one
important legal element of a contract is a "meeting of the minds" of the
contracting parties -- their mutual assent or intent. A fundamental
purpose of contract law is to enforce the mutual agreement or intentions
of the parties. Currently, the words the parties use, which often are
written down, exchanged, read, and signed by them, evidence their
"meeting of the minds." Thus, if a dispute later arises, it becomes
critical for courts and lawyers to decide what the parties mutually
agreed upon and intended based on the objective expressions they used
(typically the words in a written contract) so that the agreement they
reached can be determined and enforced.
 
XML allows content to be separated from display. This technical feature
of XML creates something of a legal problem for contracts because an
agreement can be expressed and exchanged in two separate and different
formats -- in the XML representation or in the presentation image of it.
Either can be exchanged by the parties and either can serve as evidence
of the parties' mutual agreement or intentions.
 
Because it is more likely that the presentation image (rather than the
XML) will be what most users exchange as the expression evidencing their
intent and agreement (at least when humans are involved), presentation
of XML contracts takes on particular significance from a legal
perspective.  It is difficult to see how an XML representation can be
accepted as expressing or evidencing a "meeting of the minds" or the
intent of the parties, and consequently be enforced by a court, if
neither side even knows what the XML representation contains. This is
particularly the case when the parties themselves have instead exchanged
a presentation image of the XML for such a purpose. 
 
The parties are almost certainly free to agree that the XML
representation rather than the presentation image of it is the
"official" or binding expression of their mutual agreement if they
choose, but I doubt few people will do so. If the parties look to the
presentation image of the XML rather than to the XML itself as
evidencing their mutual agreement and intentions, then a court almost
certainly will do so as well and, like the parties themselves, ignore
the XML. Of course, it would also be important to have a single,
definitive presentation image in such situations to avoid disputes about
what each side saw, signed, and agreed to.
 
I have not thought through all the legal implications this may have for
representing contracts using XML. It certainly appears that an XML
representation of a contract exchanged between two contracting parties
would probably not be the legally enforceable expression of their
agreement where they have neither seen the XML nor specifically agreed
that the XML would serve as the "binding" expression of their mutual
agreement and intent. This problem might be solved by requiring the
parties to exchange a "definitive" presentation image of a contract
document, such as a pdf version, along with the XML or perhaps by
requiring them to exchange technical details about how the XML is to be
presented (e.g. what stylesheet will be used, what browser or other
application will be used to generate a presentation image, etc.).
 
It also appears that the presentation issue has little legal
significance outside the context of an exchange between contracting
parties (i.e. the legal issue does not arise where XML is used by only
one party as a tool for administering or generating draft contract
documents), where the parties have expressly agreed that the XML
representation they are exchanging will control regardless of what the
presentation image looks like, or where only XML without a presentation
image is exchanged (e.g. with automated contracting processes involving
only the exchange of XML between machines).
 
While the presentation issue is important, I think an XML eContracts
spec would still be useful whether it creates the "conclusive" (i.e.
legally enforceable) presentation image of the XML or not. I also think
it would be helpful for an XML eContracts spec to provide sufficient
information to make it reasonably easy to create a presentation image of
the XML in case the contracting parties want or need a presentation
image for their purposes.
 
Rolly Chambers

	-----Original Message----- 
	From: Daniel Greenwood 
	Sent: Sat 4/19/2003 6:28 PM 
	To: legalxml-econtracts@lists.oasis-open.org 
	Cc: 
	Subject: 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

winmail.dat