[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] The Future We Want?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]