OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


In response to John,


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

Thank you, now we are getting to the heart of our mission.
Let me clarify one thing I might have obscured earlier. A contract is a
relationship between parties. The document or electronic record is only a
record of its terms or a means of proving the terms of the contract. It is
not "the contract" although in practical terms we may treat it as such. The
clearest example is that you and I may have a verbal agreement to buy or
sell a parcel of land. We may agree on every aspect of the contract but if
one of us turns around and says "No, we agreed to that but I'm not going
through with it", there is nothing the other party can do. In most
jurisdictions, contracts for the sale of land etc must be recorded or
evidenced in writing to be enforceable. I think its important to understand
that this is all we are talking about, the means of proving the contract.
This is purely a legal and forensic issue and I don't think we should go any
where near that issue in this TC.

Consequently, I don't think we should be concerned about digital signatures
or any issues relevant to proving contracts or the parties assent to them.
These issues will be dealt with by others with expertise in the area and in
other forums. I see the work of this TC as related to a means to markup
contract documents in a way that will help the parties to more efficiently
enter into a contract but I don't think the XML is relevant to the contract
at all unless they elect to treat an XML file as the evidential record of
the contract. Not everyone is going to use XML to prepare contracts of type
(b) or (c). Many will use other technologies but at the end of it will be a
record of a contract. In each case, the parties must be able to point to a
tangible or intangible record of their contact and say "this is it". This
will either be a piece of paper or a computer file. That computer file could
be an XML file or it could be in some other format derived from an XML file.
The fact that it came from XML and how it was achieved should be irrelevant.
There are many ways of making that translation and they will rapidly evolve
over time.

How the parties signify their adoption of a particular record (digital
signatures or whatever) is another issue. It should be up to the parties and
the legal framework in which they operate to select the record that is the
definitive evidence of the contract terms. Persons in particular industries
or interest groups may need to establish a framework for this for particular
purposes on the basis of an agreed use of XML. They may well decide on a way
of rendering or otherwise dealing with the XML markup to meet their needs.
At the moment, I don't see that as part of the broad mission of this TC.
The framework I think you are suggesting is very ambitious and I think
highly specialised. I don't think we should be starting from such a
specialised perspective. I think we should deal with all the basic problems
before addressing the specialised cases.

My core requirement would be that when we mark up the terms of a contract,
we should ensure that if the parties wish to use a plain text (Unicode) XML
file as evidence of their contract, they should be able to do so.
Essentially this is a requirement that the XML record should be self
contained as to the terms of the contract and that it does not introduce
ambiguity as to those terms. So, for example, all clause numbers and cross
references should be explicitly present and the hierarchical and grammatical
structure should be evident. I would go on to propose that the core,
structural markup must not signify any legal meaning, lest this interfere
with the grammatical statement of the contract terms. If in practice the
parties apply semantic legal markup to suit their particular processing
needs for an XML document that is treated as the evidentiary record, that
markup should be excluded from the interpretation of the contract, just as
is often the case with legislation where clause headings etc are treated as
not being part of the legislation for interpretation purposes. Whether the
standard can ensure this outcome is doubtful. Of course, if the parties want
the markup to be legally significant, that is up to them. I think they would
be heading into uncharted waters.

When the TC was formed I and some others objected to the use of the term "e
contracts" but were out voted on that point.
I am interested in using XML as a means of preparing the terms of all of the
4 types of contract as a facilitative process for the parties but whether
XML was used along the way is no more important to the contract than if it
was done in RTF or any other markup. The most concise statement of my
objectives for the TC would be "To develop a standard for the use of XML to
facilitate contract preparation". When stated in this way, I don't see the
use of XML for contracts as being any different to its use for many other
documents prepared by lawyers and others in their day to day work.


Now that may not be everyone else's expectation so this is why we need to
have this discussion. What are we trying to achieve?

Regards
Peter Meyer

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]