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