Prospective Member Welcome and Suggested Debate Convention

["Daniel Greenwood" <dang@MIT.EDU>]

Peter - I'll read your e-mails in more detail shortly (am on the road with
business travel since our last TC meeting and it is hard to devote heavy
time to these messages at the moment), but it is evident from your posts
that you are interested in getting involved in this effort.  Welcome aboard.
You were an active member of the old LegalXML and we're always happy to have
more active members of OASIS.  I am pleased to note that the culture at
OASIS is quite different and we're very focused on finishing our work here.
And I'm delighted to say that this TC is already well underway toward our
goals.

Perhaps, you are unaware that we are in the midst of a requirements setting
phase now - which is why we don't yet have our requirements.  We have a
process for gathering requirements that allows for all the discussions we
are having now.  This information should clear up most of what I think you
are saying.  Also, it is very important to note that to date, some of the
items you directly argue against (e.g. semantic contractually relevant
markup in the scope of our eContracts specification) have already been
agreed.  Other issues you bring up involve processes already in progress
(e.g. identifying our range of envisioned scenarios and tracking those back
to types of contracts and other requirements).  I do not wish to unduly
stifle discussion, but your sudden presence "on the scene" along with the
volume and sharpness of your demands upon process and substance of this TC
suggest that it would be beneficial for you to get more background on where
this TC currently stands and how it is operating.  It might be a good idea
for us to schedule time for a call or find another opportunity to get you
caught up on the TC as a way to assure you have sufficient context and also
as a starting point for you becoming a member of this TC under the rules of
OASIS.

Jason (who is chair of the requirements workgroup and also vice chair of
this TC) and I will be moving the requirements setting process to conclusion
over the coming few meetings.  In the meantime, it is a good idea to further
structure the discussions at this phase of requirements setting.  The
current issue on our agenda is whether and to what extent there will be a
requirement related to presentation/display and, relatedly, to what extent
our specification will address the final "signed contract" (though we
appreciate that all contracts do not follow this model).  We have
established a couple of key questions that are in a "votable" format for
discussion by this TC and that we feel will assist us in concluding
determination on this potential requirement.  For the time being, however, I
am not calling for a vote.  Instead, we have agreed on the last call to
further discuss the questions, assure there is agreement that they are the
right questions and phrased correctly, and then discussion of the merits of
the point.

To keep the discussion organized, what do people think about the following
convention: a unique subject title for each of the questions we have posed
(paraphrased, 1. presentation requirement generally, and 2 CSS requirement
specifically) to contain debate on each question preceding a debate.  We
also need to conclude the structural model topic and some other items from
our agenda that were eclipsed by the presentation issue.  My thought is that
this subject naming convention will free up the list for general discussion
of our other issues, while we move deliberately to formal closure of the
presentation requirement question.

Thanks,
 - Dan

==============================================
|  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: "Peter Meyer" <pmeyer@elkera.com.au>
To: <legalxml-econtracts@lists.oasis-open.org>
Sent: Friday, April 25, 2003 7:39 PM
Subject: RE: [legalxml-econtracts] The Future We Want?


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