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

["jmessing" <jmessing@law-on-line.com>]

"Meeting of the minds" takes on a new dimension when one or both of the contractants are computerized agents.

I always was told that the test was Corbin on Contracts, which is slightly different. "Objective manifestation of assent." That is, each party assents by manifesting objectively an intent to do so. The standards have subtle differences in the cases, with sometimes drastically different results. I think with regard to a strict presentation format, perhaps the Corbin formulation may be superior, at least with regard to the issues of structure vs. presentation issues.

---------- Original Message ----------------------------------
From: "Chambers, Rolly" <rlchambers@smithcurrie.com>
Date:  Sun, 20 Apr 2003 20:05:07 -0400

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