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

["John McClure" <jmcclure@hypergrove.com>]

Peter, Thanks for the questions.

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

	In the immediate run, yes. With digital signatures, with the ongoing adoption
of paperless workflows, the answer is no. [If by electronic transactions you
mean something that is not signed by human parties, then I don't think that
would have any more legitimacy than a verbal contract.]

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?

	Parties are legally free to use any kind of presentation dialect for their
contracts.

3. If we are to mandate particular presentation formats, in what
circumstances and why (business reasons, not technological reasons)?

	We are, but we are not. In business terms, the TSpec should establish that our
standard works with -- is technically feasible given -- existing Internet
technologies. In that respect, requiring users of the standard to create
documents that work with existing and universally-deployed Internet
technologies, we are mandating particular "formats". But we are not, also,
because by following W3C standards our elements can be painlessly embedded
within a datastream encoded in a dialect of the author's choosing.

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

	Not for generating particular presentation format. But we do need to provide a
standard for the markup required to make hyperlinking work in a non-intrusive
transparent way.

5. If the answer to either of 3 or 4 is "yes", how do we expect that we
would get compliance?

	If you mean certification, it seems a matter of one or several XSL stylesheets.

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?

	Most commonly sent as the body of an email, however that hardly represents the
majority of scenarios that envisage hyperlinking.

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

	Sure, as a matter of contract law. Bear in mind that one can always hyperlink
to a file such as PDF regardless of its content, protocol, etc. The VALUE ADD
that our standard provides is a method to link to content internal to the
contract.

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

	No. Neither letter nor contract need to be coded in XHTML. Given present
technology, such as Outlook and Word, the letter (can be) an XML stream that has
an XHTML <a> element within it, or has a script attached to it that effects
hyperlinking using any element of their choosing; the technology binding these
together, the same used by XHTML, is the URI (Universal Resource Identifier).
The contract itself can be coded using any XML dialect -- yours, mine, anyone's.
We don't care about the hyperlinking mechanism the users have, we only care that
they can specify a URI to content internal to a contract.

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

	not applicable, but I do expect that contracts will (continue to) be written in
mutliple dialects -- private dialects, W3C dialects, and OASIS dialects.

(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.]

	Ultimately, I see all documents "on" the web. I see a relatively paperless
society. Belief in the long-run perfections of capitalism would argue such, as I
am a trained econometrician.

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

	That is handled by other mechanisms, out of our scope. Generally such
authentication is in the realm of applications design, not protocol standards
development.

(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 they don't. The world at large will likely continue with plans about the
XML-ification of their legal documents totally irrespective of us; most will
likely settle operationally on a small group of proprietary and non-proprietary
tools. If the tools don't meet our standard out of the box, my every expectation
is that such deficiencies will be resolved by the marketplace we aim to exploit,
quite rapidly.

(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"?

	That's up to the parties. I have no expectations about this.

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.

	As Dan pointed out, linking seems to be an issue at large in LegalXML and
elsewhere, so I agree that this is potentially an issue "larger than us". I
believe however that citations must be addressed by each stamdards group,
individually, because the actual form of the citations is to information in
their domain. Because citations follow the logic of the thing cited, the
citation must be stated relative to the data model that is within the domain
staked out by the standards group.

	In other words, we should unambiguously state in our specification how
citations to any content within contract documents must be formed, that is, if
hyperlinks to markup in our dialect are to work. The consequences of them NOT
working is that noone will use our standard. Period.

	With regard to the click-through XHTML contract, for hyperlinking to work,
without a-priori knowledge of the values of id's in a file -- which includes
*all* manual copy/paste operations -- requires that the XHTML has mixed-in
container elements that identify the blocks of text as Blocks of legal
information.

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.

	They're not off the mark if they help to limit the impact of resolving my
concerns.

	The business explanation is that, to make hyperlinking work properly for now
and in the future, the standard must incorporate the architecture for the Web as
envisaged by the W3C.  Their architecture is fundamentally based upon the use of
XML Namespaces, which specifically envisages XML datastreams of mixed namespace
elements (and formulated by the same persons as  SGML Architectural Forms).  The
standard will be far less complex, far less controversial, and far less isolated
if we *use* the W3C's architecture to meet our *functional* goals: (1)
extraction of information from a contract (2) exchange of meta-data about the
contract (3) standard hyperlinking to internal content. Using the W3C's
well-documented architecture means that we must address the dialects of XML
devised by the W3C to represent contracts, to link to contracts, and to
represent metadata. In so doing, as a direct consequence of their architecture,
our standard can (then) be used *equally* within non-W3C dialects for a
contract -- a dialect as chosen by the parties -- and includes such as OASIS'
DocBook or MS' proprietary document markup.

	The counter business arguments to these points are weak, all based on the
premise that we should first develop a dialect of XML that is an island within
the sea of technology. Creating a standard that does not easily and provably
allow standard hyperlinking to the content of a contract virtually assures that
the standard remains on an island un-connected with the rest of the Internet.
That is not a recipe for a standard that, by itself, has to establish a
credibility we need in order to market the standard successfully. Our numbers
are small, but if our words are true, they will heed.

Optimisticly,
John