[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] Display/Presentation Agenda Item: Proposed Wording Second Draft
Hi Dan, I'd just like to qualify the meaning of you 2nd draft question? Your question could be read to be asking whether we will prescribe a presentation as part of the standard? One of the powerful underlying opportunities of xml structured documents is the ability to render the presentation to suit the purposes of the user. Structure, content, nomenclature, language, etc. can all be usefully acquired or transformed from a good xml standard. My conviction is that the TC should work towards a non-prescribed presentation of the standard. This should be simple and ubiquitous with perhaps multiple versions to support the various presentation options such as XHTML, XSL, CSS and SVG. The key point here is that we should not prescribe the presentation we should merely exemplify the presentation as a practical extension of the standard process. This is an important question that will determine the direction and validity of the TC efforts. Thanks Eddie -----Original Message----- From: Daniel Greenwood [mailto:dang@mit.edu] Sent: Wednesday, April 23, 2003 2:34 PM To: 'Legalxml-Econtracts' Subject: [legalxml-econtracts] Display/Presentation Agenda Item: Proposed Wording Second Draft This is the latest way John McClure has characterized the need to address "presentation" (e.g. display) of the contract as a requirement "Our specification must accommodate the final XML presentation of the contract, not a precursor to the presentation -- people sign the presentation, not the precursor. . . I think this is the fundamental question for today - are we exchanging a 'real' contract or not?" The answer to these questions *could* be no. This TC could choose to count final contract display (i.e.: the "real contract" for many current legal scenarios) as out of scope. In this vein, the TC would be creating a standard to enhance negotiation and management of contracts, but in many situations not the "contract itself". It is possible to include a comment in the specification indicating the need for implementers and users to address the displayable and executable contract through other means, and perhaps to provide examples. On the other hand, if this requirement is accepted and inside the scope, then implementation of our final specification(s) would need to reliably result in identical display between the multiple parties to the contract. One of the implications is that any interoperability testing that we might need before finalization would necessarily have to include successful demonstration of this feature. Of course, until we determine that this is in fact a requirement, it is a question and not an assumption. Given all that, I propose phrasing the requirement discussion around the following second draft wording: [Second Draft] Yes or No: The final eContracts specification will encompass and directly support the final, conclusive displayed version of a contract that is agreed by the parties. [/Second Draft] For comparison's sake, here is the prior draft: "Yes or No: The eContracts spec shall define an exchange standard (XML Schema or DTD) that includes the information needed to create conclusive presentation of the contract as agreed by the parties,without the need for an intervening transformation via XSL-T or similar process." Thanks, - Dan Greenwood
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]