[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Autonumbering - a non-issue
Jason said: >I'm not sure i get what you are driving at here. I've always used >stylesheets to apply appropriate numbering to the clauses - you might >call this autonumbering. This way, if you edit the contract and move a >clause or promote or demote it, it will automatically get the correct >new number. > >One of the questions we haven't discussed yet, is whether there is a >need to be able to explicitly number each clause (ie if you don't want >to leave this to your stylesheet). > Actually, we have discussed this important question ALOT. I believe that a "safe" contract has no generated content at all! From a perspective of minimizing the probability of subsequent repudiation, I personally would be loathe to field an application in which the parties sign anything other than the presentation form of the contract, ie its HTML, XSL-FO, or SVG form, or an XML form that references ONLY a CSS stylesheet -- that is, an exact replica of the contract as it was presented to them for their acceptance. In other words, it is the OUTPUT of an XSL-T stylesheet that is relevant to interchange. With any of those output formats -- HTML, XSL-FO, SVG, and XML/CSS -- there is no possibility of generated text as a side-effect of information transformation technology. It is chiefly for this functional reason that I think eContracts standards need to accommodate HTML, SVG, XSL-FO, and XML/CSS markup only. I have to spurn the idea that we should be designing for XSL-T. XSL-T, with its ability to generate content (including caption numbers) of course is important to the process of creating the HTML/SVG/FO/XML-CSS rendition -- but that's all application level processing merely in preparation for digital signing of the presentation artifact. My understanding is that this group is NOT designing applications -- we are supposed to be designing the datastream(s) that can pass between applications. I have demonstrated that it is very easy to annotate the content of an HTML/SVG/FO datastream with terms from our vocabulary. To wit: <p title='Clause'> <span title='Clause.CaptionNumber.text'>15.1</span> <span title='Clause.Caption.en'>Non-repudiation</span>. <span title='Clause.Content.en'> This digital contract, encoded in HTML, cannot be repudiated on the basis that its parties cannot replicate the processing steps necessary to render the contract prior to its acceptance by parties to the contract. There are no parameters supplied to the processing from the outside environment relevant to rendition of the contract image. There is no external computer file necessary to render the contract image. This file is fully and completely all that is necessary to render the contract image at any time by software created in conformance with W3C sanctioned standards for HTML 1.0. The contract was rendered at the time of digital signing by Internet Explorer, version 4; this software processes HTML files in accordance with W3C sanctioned standards for HTML 1.0. </span> </p> By using the "title" attribute, then the names assigned to all displayed text is equally displayable by a user's browser, another bulwark to non-repudiation. Further, I have provided XSL-T stylesheets that will transform the above HTML markup into "standard" XML: <Clause> <CaptionNumber><text>15.1</text></CaptionNumber> <Caption><en>Non-repudiation</en></Caption><en>.</en> <Content><en> This digital contract, encoded in HTML, cannot be repudiated on the basis that its parties cannot replicate the processing steps necessary to render the contract prior to its acceptance by parties to the contract. There are no parameters supplied to the processing from the outside environment relevant to rendition of the contract image. There is no external computer file necessary to render the contract image. This file is fully and completely all that is necessary to render the contract image at any time by software created in conformance with W3C sanctioned standards for HTML 1.0. The contract was rendered at the time of digital signing by Internet Explorer, version 4; this software processes HTML files in accordance with W3C sanctioned standards for HTML 1.0. </en></Content> </Clause> Now, this XML/CSS form can be just as easily exchanged as the HTML/XSL/FO form -- although it's a little tricky if the CSS stylesheet is to be incorporated into the same file as the contract itself -- but beyond this, the important thing is that it is CSS that is the point of design, not XSL-T. Given CSS, then there is NO generated content. Given no generated content, then the answer to your original question is that EVERY caption in the contract should be already numbered by the time it is interchanged. John McClure
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]