Re: [legalxml-econtracts] Requirements - XML and the contract

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

To help inform the discussion about RDF and XML, there is an article
entitled "Make Your XML RDF-Friendly" at
http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html that is worth reading.
It makes a number of the suggestions John McClure has made.

This discussion also has echoes of the "document vs. data" divergence within
the XML community.

Also, see my responses to your questions below. I have every confidence that
John will let all of us know where he thinks I've gone off track.

Rolly Chambers

----- Original Message ----- 
From: "Peter Meyer" <pmeyer@elkera.com.au>
To: "Legalxml-Econtracts TC" <legalxml-econtracts@lists.oasis-open.org>
Sent: Thursday, October 23, 2003 12:03 AM
Subject: [legalxml-econtracts] Requirements - XML and the contract


> Hello TC members,
>
> Following our latest meeting, the plan is to review John's linking
> requirements at the next meeting.
>
> I am a non technical person and have to rely on our programmers to guide
me
> on more technical matters. I confess to being rather confused about just
> what John is asking for and would appreciate some clarification before the
> meeting.
>
> At the moment, it seems that we really have to understand the role of XML
> and the contract before we can understand what John is asking and how his
> requirements might be addressed.
>
> To assist, I would appreciate it if John will elaborate on his
requirements,
> using the questions I set out below as a basis for discussion. In so
doing,
> I ask John to please not mention RDF, CSS, XSLT or any other particular
XML
> standard or processing technology of that ilk. I think we need to
understand
> how it should work from a user and business perspective, not a
technological
> view point. Forget you are a technologist and tell me what you want as a
> visionary businessman. If you could do this John, it really would be a big
> help and very much appreciated. Once we understand the needs, then the
> technical issues can be addressed.
>
> My questions (firstly to John, but anyone else can have a go):
>
> 1. Do we agree that the XML document used to generate the contract
document
> will rarely, if ever be the evidentiary contract document? [I envisage the
> exception may be in some automated electronic transactions.]
>
[I think so. However, I believe that as a legal matter, the contracting
parties are free to decide that the XML document (rather than the
"presentation artifact") will indeed be their "evidentiary contract." They
could legally agree that each party will display the XML however they want
just for information purposes, but that the resulting "presentation
artifacts" will not be their "evidentiary contract." This of course presents
a risk of confusion and other potential difficulties because one party may
display the XML document differently from the other and it may require the
parties to work with unfamiliar XML markup or learn new XML editing and
other applications. However, it would be "legal" for the parties to use the
XML document as their "evidentiary contract" if they choose.

I think John believes only the "presentation artifact" should serve as the
"evidentiary contract," because it (as opposed to the XML document) more
reliably captures the content that both parties have exchanged, seen, used,
and relied upon to express their mutual agreement. It is better evidence of
their mutual intent because it avoids problems with dynamically generated
"presentation artifacts" via stylesheets or programming functions that can
differ from the one the parties actually exchanged and agreed upon. The
"presentation artifact" also contains the rendered datastream that users
will most likely be familiar with and will be trying to create or edit.

When John says the presentation document is or should be the only "legal"
contract, I understand him to be saying that only the "presentation
artifact" ought to have any evidentiary value if a question or dispute about
the contents of the contract document arises. I also understand him to be
saying that even if the parties are legally free to take the risk of
confusion and other potential difficulties that would come from using the
XML document as the "evidentiary contract," we should not allow this in the
eContracts standard.]

> 2. Are the parties to contracts free to use any kind of presentation
> document as the evidentiary form of the contract or is it necessary for
the
> standard to mandate particular presentation formats?
>
[The contracting parties are free to choose any presentation document or the
XML document itself as the evidentiary form of the contract document. There
isn't any need for the eContract standard to mandate a particular
presentation format from a legal perspective.]

> 3. If we are to mandate particular presentation formats, in what
> circumstances and why (business reasons, not technological reasons)?
>
[I think John is saying that annotating existing presentation formats such
as XHTML with an eContracts vocabulary means existing browsers (instead of
special eContracts applications) can be used to display the presentation
artifact. It means less training for the people creating the eContract
presentation documents since they or the editing applications they already
are familiar with can be used. He thus reasons that the TC needs to focus
only on coming up with the eContracts semantic vocabulary and not consider
structure or presentation at all.]

> 4. Is it necessary for the TC to mandate or recommend any particular
> processing technologies for parties to generate particular presentation
> formats and, if so, why (just business reasons)?
>
[No particular processing technologies for generating presentation formats
should be mandated. However, the TC should not create an XML syntax for
contract documents that cannot be used with XML-compliant processing
technologies. The TC should create something that is capable of being used
with any other processing technology to generate a presentation format.]

> 5. If the answer to either of 3 or 4 is "yes", how do we expect that we
> would get compliance?
>
> 6. John recently set out a scenario in which he envisages a party sending
a
> letter with references to contract terms. I treat that example as fairly
> representative of some of the linking issues that may arise. John wants a
> link from the letter to the contract terms. John, please expand on this
> scenario and explain how you envisage this will work:
>
> (a) Do you agree that the letter would most commonly be printed, rendered
as
> a PDF document & attached to an email or sent as the body of an email?
>
[The uses listed are common, but not necessarily "most common." The letter
will also be stored, retrieved, read, and edited by the author or recipient.
Additionally, if it is in a machine-readable form, some of its contents may
be automatically "read" and re-purposed/re-used by a machine instead of a
person.]

> (b) Do you agree that the contract may have been generated from an XML
> source and then printed or rendered in PDF or some other electronic form
> chosen by the parties to provide their evidentiary contract document?
>
[Yes. The printed or PDF forms will have the capability to be read and
processed by people but will not have the capability for any automated
handling by machines. Cutting out the possibility of machine processing
essentially means to me that generating the documents from XML is simply one
more way to generate a contract document in print or PDF with an ordinary
word processor or PDF application.]

> (c) Do you envisage that the letter and the contract must be in HTML or
some
> other similar format on the sender's or someone else's web site so that
> linking can occur?
>
[It would need to be in some format that supports links.]

> (d) If so, do you expect that everyone using the standard MUST publish
> everything generated from standard XML in HTML or a similar format?
>
[No.]

> (e) If not, what documents in our area of interest do you expect to find
on
> the web? [I can think of some that will, so don't get me wrong here.]
>
[Licensing agreements, some types of consumer agreements, and some types of
public government contracts on the web. Just about any type of contract on
an intranet or extranet.]

> (f) If they are expected to publish documents to HTML, how do you deal
with
> confidentiality, security etc that must surround most contractual
> transactions and related documentation?
>
[Security and confidentiality can be addressed by digital signatures and
encryption, as well as by general network and system security measures.]

> (g) Does everyone have to use the same technology to produce the HTML (or
> whatever) and, if so, why (without discussing merits of any particular
> technology)?
[No.]

>
> (f) If the contract is in HTML or similar form on someone's web site, is
> this HTML version just a rendering of the contract terms for information
> purposes or do you expect it to be "the evidentiary contract document"?
>
[I think John expects it to be the "evidentiary contract document." I think
it could be either the evidentiary contract document or just a rendering for
information purposes depending what the parties agree.]

> 7. These questions are rather broad and do not distinguish between
different
> types of contracts or user communities. Are we talking only about
contracts
> that arise from particular types of transactions, say web site click
through
> contracts or something else? Please elaborate.
>
[I am thinking of electronic contract documents that capable or being read
and processed by both machines and people as opposed to those that are
capable of being read and processed only by people. I am not thinking in
terms of any particular type of transaction.]

> 8. Finally, if my perspective on this is so off the mark that you don't
> think these questions allow you to explain your requirements, please feel
> free to provide further explanation. Again, I would appreciate it if you
> could avoid discussion of any particular technologies, at this stage and
> focus on the business needs.
>
[I think your perspective has focused on using XML as a way to solve
problems of creating and presenting structurally complicated contract
documents so they can be used by people, which has my support. I am not
certain this perspective has fully considered other situations in which
information in contract documents also needs to be read and processed by
machines, a perspective which also has my support.]

> I look forward to hearing from you.
>
> regards
> Peter Meyer
>
> --------------------------------------------------------------------------
-
> Elkera Pty Limited (ACN 092 447 428) - Knowledge management
> Email: pmeyer@elkera.com.au
> Ph: +61 2 8440 6900 * Fax: +61 2 8440 6988
> http://www.elkera.com.au
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php.
>