I have long been concerned about the impact should an attorney or judge be unable to link to an XML element that is in material generated dynamically, such as, by action of an XSL stylesheet. Here is a common scenario that must be accommodated by our standards: an attorney receives a letter that cites a clause within a contract. The letter-writer wants that citation to be an hyperlink to the clause. Are we creating a standard that facilitates or defeats this common scenario?
The tests below were created to provide a sandbox for showing that links to generated material simply don't work. They were created in support of recommendations I've today made to the LegalXML eContracts TC regarding compartmentalizing markup of XML documents that the TC would purport to be useable by the general public as contractual material vs contract documents that are encoded in a so-called presentation dialect (SVG, XSL-FO, XHTML, and XForms).
The results were surprising to me, as I think they will be for you.
Selecting <a href='LegalDocument.xml'> displays a document generated by IE. Scroll to the bottom, and note that it reports that:
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.
The system cannot locate the object specified.
This message is displayed because the XSL stylesheet contains a document() function
that references an invalid URL. Assume that the URL is for a web-service, which is not
available some time after a contract has been formed, but was available when the contract
was digitally signed by the parties. The above message would be displayed at that (later) time.
Selecting <a href='LegalDocument.xml#idP3'>
displays the final paragraph. The IE browser generates the output document by
application of the LegalDocument.xsl stylesheet against the LegalDocument.xml
input data file, and then (correctly) searches for the id specified.
So, I stand corrected after so long thinking that this kind of linking does not work.
Selecting <a href='LegalDocument.xml#idP'>
displays the top of the generated document. The IE browser generates the output document by
application of the LegalDocument.xsl stylesheet against the LegalDocument.xml.
Selecting <a href='LegalDocument.xml#idElement'> displays the top of the generated document, because the id exists only in the source document, not the generated document.
The tests showed that linking to generated material does work. However, there is one caveat. The id for an element in the generated material formatted by the XSL stylesheet must be determined by inspection (automated or not) of the generated material; these id's cannot with certainty be determined by inspection (automated or not) of the source xml material. Therefore, a well-informed design of a standard for XML contracts should endevour to establish that annotations of a semantic nature are directly integrated with the (XHTML/SVG) elements that are output by XSL stylesheets operating against eContract-encoded XML files. These annotations enable automated identification of elements corresponding to important semantic information, thereby allowing the creation of links to that information, within the generated presentation of the contract document.
And what of common citations, that is, links to structural elements within the contract?
XPATH expressions can provide linkage to a specific structural component of a contract, without a need to know a-priori the "id" assigned to that specific structural component (if any). Using XPATH is technically feasible only as long as the element(s) that represent the structural component can be "selected out" of the presentation datastream. Two possibilities exist:
The advantage of the first method is that it could provide a technical framework for annotation of semantic information within the contract, presuming that it is unrealistic to encapsulate the semantic data with XML elements (though this does run counter to Jason's recent musings of stand-aside "non-structural" markup for semantic information).
The advantage of the second method for identifying structural elements a-priori is its use of eContract elements in the generated output stream. This could provide a compelling reason for users to adopt the eContracts schema assuming that the LegalXML standard for citations would be amenable to adopting those elements as the "markers" of the structural elements within the file.
The sad reality, though, is that these shenanigans would be totally unnecessary, had the TC decided to create a standard that supports direct CSS formatting of its markup as presentation material. The TC decided to defer (sic) that requirement though -- long held as of primary importance by certain members of the LegalXML of yore.
Given present circumstances, the eContract standard should address the way that XHTML and SVG elements are generated when presenting the contract. It is unnecessary to recommend that a presentation dialect be used for an executed contract exchanged between parties. However, in order to facilitate external hyperlinking to specific structural and semantic information within the contract, the standard needs to address annotations or encapsulation of XHTML and SVG elements generated during presentation processing of a contract.