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

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

Hi Peter, good to hear your voice again.

Your 4 types of contracts are fine with me -- I believe though that the (b) and
(d) types are the only ones relevant to a TC creating an XML schema for 'a legal
contract expressed in the Extendable Markup Language'. From your remarks, it
appears you believe that 'the contract' is an item that includes a manifestation
of its acceptance by the parties. For type (b), you see digital signatures
providing that manifestation. For type (d), you are understandably concerned
that there is no manifestation maintained TOGETHER WITH the contract artifact. I
think you're right that our working definition of 'a contract' needs to
encompass that manifestation. So, for purposes of argument, let's assume that a
digital signature is the only technology worthwhile accepting as indicative of a
manifiestation of one's assent to an XML stream purporting to be 'the contract'.
What does that mean?

It means that we must prove that the digitally-signed datastream, at a later
point in time, is the same as that originally signed. That's no problem -- we
all feel comfortable with hashing algorithms provided by digital signatures to
do that job. BUT when the datastream that is signed includes EXECUTABLE
material -- in contrast to raw "printer instructions" -- then we must provably
show that the same executable *environment* as that which existed at the moment
of signing can be re-created at any time in the future. But that is so very hard
to prove when the executable (like an XSLT styelsheet) is able to access any
resource on the web during its "formatting" -- ah, let's be real: its
transformation -- of its input XML datastream(s).

Yes, our working definition of 'an XML contract' needs to encompass a
manifestation of assent in order for that datastream to be validly called 'the
contract'..... that digital signatures are the right technology for that
manifestation ... and that the digitally-signed material include at least the
'raw' printer instructions themselves expressed in XML using either the
XHTML/CSS, XSL-FO, SVG, or eContracts/CSS dialects. I believe that the schema
being defined by the TC is not for 'a contract expressed in XML', but rather it
is for a 'negotiating document expressed in XML' which, when combined with
boilerplate, and when formatted, and then when signed, only then yields a valid
and legal contract.

So we really are trying to achieve the "clarity" of requirements that you're
encouraging -- one of the first orders of business being whether this TC's
present set of requirements relate to "a contract" or to a "negotiating
document" that can be later transformed into "a contract".

If the TC does not want to address presentation, then that is FINE as long as
the TC stops labelling the schema they're building is for "a legal contract" --
the notion of "contract" and "presentation" are simply inseparable for the vast
majority of contracts executed in most contexts.

John McClure