RE: [legalxml-econtracts] The Future We Want?

["Peter Meyer" <pmeyer@elkera.com.au>]

John McClure wrote:
>
> Jason,
> I wish I were just an alarmist, but I am being factual. You say
> that one "_can_
> use XPath and XQuery" is true only as it applies to a PIECE of
> the contract --
> one cannot use XPATH to link to a virtual image created by
> applying the XSLT
> stylesheet referenced by the XML stream; other PIECES of the
> contract can be
> located in that XSLT stylesheet, a fact whose consequences have yet to be
> addressed by anyone in this TC.

I think this may be relevant to the inclusion of cross references within the
document as well but will leave that to the more technical members.

>
> You also say "if there turns out to be a discrepancy between the
> XML and the
> thing they signed, then the latter is what counts" -- is my
> contention, that the
> XML that this TC is defining is NOT the definitive contract, so
> the TC should
> either (a) stop calling the XML a "contract" and call it, instead, a
> "negotiating document" or (b) address the issue = standardize
> what sort of XML
> *can* be called a "contract" -- which I believe is either an
> XHTML, SVG, or
> XSL-FO datastream, or one conforming to the eContracts schema,
> displayed using a
> CSS stylesheet.

There is a complete lack of clarity in what people are talking about that is
the problem here. As I mentioned before, the problem is that the TC is
talking implementation before it has set out requirements.

As I see it, there are at least 4 types of contract that could be under
discussion:

(a) contracts that are recorded and signed in written (printed) form
("signed, written contracts");

(b) contracts that are recorded only in electronic form and that are signed
by the parties using a digital signature technology that identifies the
signer and determines whether the electronic record has been altered since
it was digitally signed. I will call these "digitally signed electronic
contracts"; and

(c) contracts that is represented in printed form but are not signed by
anyone or by only one party. Commonly, the terms are incorporated into a
contract where the offer and acceptance is signified by conduct of the
parties. A printed shrink wrap licence in a software package is an example.
Another example is a contract that arises when one party writes a letter to
the other to make an offer that can be accepted by the recipient taking some
action. Lawyers probably have a term for these but I will call them
"unsigned written contracts".

(d) contracts similar to (c) but which exist only in electronic from.
Examples may be many shrink wrap contracts formed on web sites where neither
party prints out the record of the terms. Again, there may be a more common
description but I will call them "unsigned electronic contracts". Of course,
if someone prints it out, this may really be case (c).

Both (c) and (d) may technically be oral contracts with their terms
ascertainable from written or electronic records. I am too far removed from
legal practice to know the technicalities now.

I acknowledge there are some ambiguities in use of the term "written"
because often, electronic records can be regarded as writing for evidence
laws. I use the term for something that is in a tangible form (ink on
paper).

Others may have a better classification of contract types for purposes of
these discussions. There may be other types we should understand. I would
welcome correction from an expert contracts lawyer.

My basic point is that we have to be clear about the types of contract we
are addressing and the requirements in each case.

Turning to these in turn.

(a) Signed written contracts
What is the difference between a contract prepared in XML and one prepared
on a word processor? The only record of the contract that is relevant is the
written record. If this should be lost and one or both of the parties wish
to prove the contract in some other way, the electronic record may become
relevant but this is exceptional. In that case, why is the XML different to
one that was saved as RTF and then displayed using a different version of
Word or in WordPerfect. In all cases, the rendering may well be somewhat
different to that used to print the original.
Basically, I believe the XML is and should remain irrelevant to these types
of contract, just as the RTF or whatever is irrelevant now. Essentially, the
XML is only ever part of the draft contract. It never represents "the
contract".
If we are looking at it from the perspective of normal business contracts,
this should be the focus of our work.

(b) Digitally signed electronic contracts
I don't know whether the layout of an electronically rendered contract is
significant. Obviously it would be convenient but I doubt it is essential. I
can't see any reason why a raw XML file could not be sufficient. The parties
lawyers would have to explain all the tags to the judge but after crossing
that barrier, I am sure everyone would move on and get down to interpreting
the words in the usual way.

My view is that the significance of markup will be whether it sufficiently
differentiates the components of the contract to avoid ambiguity. The
classic problem is in complex grammatical structures such as lists which
revert at various points to the containing list paragraph or the enclosing
paragraph. You need to be able to work out which paragraph a particular line
belongs to. In print, this is usually signified by indentation but that
would not be available in electronic records. The markup should be explicit
on this point.
Again, others may differ, but I believe that the issue of rendering the
contract is entirely up to:

(i) the parties to the contract; or
(ii) the requirements of a legislative framework for particular kinds of
contract.

Any parties entering into an important digitally signed electronic contract
should obtain their own legal advice about the process until the process
becomes well understood and settled.

I don't see how we can or should solve it to everyone's satisfaction. Our
only requirement should be to ensure that the markup is sufficient to
delineate the grammatical structures. This is not very difficult. HTML
markup would not be sufficient, in my view, for complex situations.

(c) Unsigned written contracts
The problem here is basically the same as in (a).

(d) Unsigned electronic contracts
The problem is likely to be more complex than the other cases. There are
real problems in proving the terms of the contract regardless of the
presentation issue. It is very likely that if I go back to any web site from
which I have downloaded something and accepted a click licence, I could not
find the terms of contract I supposedly accepted. It is also very likely
that the supplier has changed their terms since and the version I accepted
is not now published on the site. It would be interesting to know how many
cases have a reliable way of identifying the actual set of terms agreed to
with each contract. I suspect that this could be a serious problem for most
sites.

There are many issues with these types of contract. Many different
technologies are used to render the source wording (markup) and this will
continue. I believe it is beyond the scope of this exercise to address the
issue of rendering.

If someone has a requirement for a particular scenario that requires that
rendering is addressed, this should be clearly identified. It would then be
a question of whether this should be left to a particular interest group or
incorporated as part of the general requirements. My expectation is that we
should confine ourselves to the basics at this stage and concentrate solely
on structural XML markup. Particular presentation technologies should not be
relevant. Of course, we would want to develop markup that people can work
with using known technologies but that does not mean that people have to be
able to print a beautifully published contract document with contents
listings, headers, footers, footnotes etc using CSS. If CSS evolves to
provide such functionality that's great. If it does not, there are other
technologies that can do it. We are not concerned with this.

Overall, I believe we should stay away from the issues of contract law. I
believe our mission should be to ensure that we do not make the markup
relevant to the contract at all. People will use non XML technologies to
achieve the same aims. I believe contract law is and should remain markup
agnostic. A raw XML document should be capable of being a valid electronic
contract if that is desired by the parties. Our job is to make sure the
markup correctly reflects the grammatical structure of the contract. If one
or both of the parties wish to add legal semantics to the markup of the
electronic to assist them during the contract creation process or in some
other way, that is a matter for them but it should not be part of any
standard from this TC. At most, we may provide a framework which allows them
to add this to the markup if they wish.


regards
Peter Meyer