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?


Dear TC members,

In my earlier posting on requirements I seem to have covered some ground
that was resolved in your phone meeting earlier (presentation, in
particular). Unfortunatly, because I have not been actively involved I did
not know the meeting date and time and did not recieve the details until too
late. I think the details were only sent out a few hours before the meeting
which was in the wee hours down under.

Please ignore aspects of my message that are negated by earlier decisions.

Peter Meyer




>
> The other consensus tentatively polled today (correctly in my view) was
> that presentation is out of scope.
>
> That means that the XML purporting to represent the contract is just
> that - XML.  Crucially, it is a representation of the contract.  It can
> be validated against the schema to be developed by this TC to verify
> that it is in fact a contract (as understood by software ).  Its also
> the contract, as understood by the parties - see further below on this
> point.
>
> So, to address your alarmist contentions, you _can_ use XPath and XQuery
> on the contract.  You _can_ search for a caption.  And the caption
> numbers _can_ be hardcoded (see the example markup both you and I
> posted).  Of course you can cite a specific part of the contract.
>
> Mentioning XSLT at this point is a red herring.
>
> This XML purporting to represent the contract is  _the_ contract,  not
> just as understood by software, but as understood by the parties.  And
> it can be visualised and recorded for posterity however the parties
> wish.  It is that visualisation, or presentation format, which the
> parties are likely to sign.  Whatever format they choose (be it the raw
> XML, which is likely in agent-based scenarios, PDF or a printed Word
> document (both of which are likely for the foreseeable future, or CSS or
> SVG) is their choice, and will be the document referred to if the
> contract is ever seen by a court.  Again, it is not for us to dictate
> what that format is, much less decree that it can't be PDF or RTF or
> something else.
>
> This means there are quite probably several representations of the
> contract, but only one which was signed and is definitive.  Same as
> today, where there is often an electronic representation stored on a
> computer somewhere, which people can use when it suits them, photocopies
> provided to people who need them, and several signed counterparts.
>  Different representations, but only the signed counterparts are
> definitive.
>
> Another analogy: have a look at the "Available Formats" section in
> http://www.w3.org/TR/REC-CSS2/
>
> It says that the CSS2 specification is available in HTML, plain text,
> gzip'ed PostScript and PDF.  It goes on to say "In case of a discrepancy
> between the various forms of the specification,
> http://www.w3.org/TR/1998/REC-CSS2-19980512
> <http://www.w3.org/TR/REC-CSS2/Overview.html> is considered the
> definitive version."
>
> What software can do with that presentation format obviously depends on
> what format the parties choose.  For this reason, you'll probably want
> to write your software against the non-presentation XML we are
> standardising.  The XML (ie as standardised by our TC) will often be all
> the parties ever use.  That is what will end up in contract management
> systems, and will be used for generating reports etc etc.  But, if there
> turns out to be a discrepancy between the XML and the thing they signed,
> then the latter is what counts.  My understanding from the teleconf
> today is that this is well understood and accepted by the lawyers in our
> midst.  Anyone care to confirm?
>
> Obviously the risk of using the XML we are standardizing in contract
> management systems etc, where some presentation format is actually what
> was signed, is on the person using it.  No different from today.  But if
> you are really concerned about fraud, and want to check up front that
> the XML version contains the same words, it is a simple matter to do so.
>  You could open the XML version in your tool of choice, and use your
> eyes to compare it to the presentation version.  Or you could use
> software to compare the characters in the presentation format (whatever
> it is, including for example PDF) against the standardised XML, and
> report any discrepencies.  Or, you could just ask how the presentation
> format was prepared.
>
> Hope this helps.
>
> cheers,
>
> Jason
>
>
>
> John McClure wrote:
>
> >To the eContracts Technical Committee:
> >
> >I am concerned about the future that your specification for
> "legal contracts" is
> >intended to foster. I understand that the consensus tentatively
> polled today
> >will allow an XML datastream purporting to represent a "legal
> contract" to
> >contain an <?xml-stylesheet> programming instruction that
> references an XSL-T
> >stylesheet. This means that there is no technical provision for
> stopping a
> >stylesheet from, for example, conditionally inserting
> boilerplate text that is
> >not in the "legal contract" datastream.
> >
> >Do you REALLY want these consequences?
> >
> >1. No XPATH Support = no XQuery support?
> >There will be no single XML datastream that represents the
> contract as SEEN BY
> >SOFTWARE. There will be no complete XML datastream that one can
> search using
> >XPATH expressions because boilerplate content is being (often,
> conditionally)
> >inserted by the stylesheet. No XPath expressions written to search for a
> >specific caption number, for instance, will ever be possible
> because caption
> >numbers are envisioned to be generated by the XSLT- stylesheet
> referenced by the
> >XML programming instruction.
> >
> >2. No XPATH Support = No Hyperlinks = No Citations?
> >There will be no single XML datastream that represents the
> contract as SEEN BY
> >THE PARTIES. There is no way to hyperlink to the actual
> presentation of any of
> >(a) specific structural elements such as an "Article" or specific "legal"
> >elements to be designed (b) specific presentation elements such
> as "Page 2, Line
> >2" or (c) any of the boilerplate content inserted by the
> stylesheet referenced
> >by the Programming Instruction.
> >
> >3. No Physical Contract Datastream = Opportunity for Fraud?
> >There will be no single XML datastream that represents the
> contract as later
> >SEEN BY A COURT. The contract's presentation is re-created each time from
> >resources spread potentially all across the web; it is easy for
> the contract to
> >contain different content at different times. XML Digital
> Signatures technology
> >is not an adequate solution because it will not package
> resources referenced by
> >the XSL-T stylesheet. If the contract cannot be (re-)created because, for
> >instance, the resources referenced by the XSL-T stylesheet are no longer
> >available, then that sounds like a contract that is easily repudiable.
> >
> >I believe these are serious substantive problems with the
> architecture that have
> >not yet been adequately addressed by its supporters. If the TC
> believes that #1
> >and #2 are technically possible with the envisioned architecture, then I
> >challenge its supporters to demonstrate this fact, or at least
> to cite some W3C
> >standard that would provide for these two items, and discuss how
> it would be
> >applied. If the TC believes #3 is not a technical issue, then I
> challenge its
> >supporters to demonstrate how an XSL-T stylesheet can be prevented from
> >accessing external resources by calling the XSL-T document() function.
> >
> >I have proposed an architecture in which the TC standardizes two
> datastreams --
> >one for the contract itself, and one for all the workflow and
> other information
> >that everyone wants to exchange during contract formation. The "workflow"
> >datastream certainly can contain instructions for generating the contract
> >datastream, including an XSL-T stylesheet that is to be applied to the
> >"workflow" datastream itself -- to generate the contract
> datastream. In the
> >architecture I propose, the contract datastream would contain
> markup relating to
> >all the structural and legal data elements. and markup relating
> to the physical
> >layout of the contract -- it is an architecture that not only
> addresses items #1
> >and #2, but also directly forecloses a glaring opportunity for contract
> >repudiation.
> >
> >Without question, the eContracts TC is presently defining a
> standard for a
> >"workflow" document, not for a "legal contract" document. Simply
> said, a legal
> >document is not mutable -- however this TC is purposefully
> defining a mutable
> >document for, allegedly, benign formatting purposes.
> >
> >John McClure
> >Hypergrove Engineering
> >
> >
> >
> >
> >
>
>
>



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