[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] December 17 Draft minutes
>John McClure: I think the next step is to develop the set of talking >points. It might still be addressed in even the January draft. If they >are undecided on something such as the NR. Here's some fleshing out of items for a "talking points" memo from our group to XHTML 2.0 TC. John 1. Support for the <section> element, with a request to specifically describe its use in the context of creating a legal instrument such as a contract. We might further indicate that we are less likely to create a <clause> element in a LegalXML XHTML module in the event that <section> is established as the markup for sequentially-numbered grammatical paragraphs, and if item #3 below can be adequately addressed. 2. Support for the <nr> element, to be used as child element to the <h> element OR as a child element to the <section> element itself. No other applications should be allowed. Jason's and Peter's requirements documents both specify the need for a "number" element (although curiously in Jason's latest screed, no such element is mentioned). The intention of the XHTML2 TC is for CSS auto-numbering facility to generate the numbers. However, not only is this a leap of faith that browsers fully adopt CSS 2.0 in this regard, but also that the section-numbering schemes needed for legal documents can be adequately represented by CSS 2.0 directives, both in terms of the actual formatting of the number and the number's proper positioning with respect to the text content of the section. 3a. Support for a <frontm>, <body>, and <backm> structure within the <html> element. The preferred objective is to use XHTML2's <section> element to represent a nominal "clause", without resorting to their proposed "role" attribute to identify a given <section> element as a clause. This relates to (1) styling the document; (2) auto-numbering; (3) how we wish to use the "role" attribute in our spec; and (4) XPATH expressions used in hyperlink citations. To my ears, Shane suggest that getting these two additional elements (frontm and backm) into XHMTL 2.0 spec would be an uphill battle; their intention is for the "role" attribute to distinguish between types of such sections. However, using the same element to distinguish between say, a "cover letter" and the actual legal instrument, or some meaningless appendix and the legal instrument(s) represented within the XHTML 2.0 markup, means section numbering using XSL must rely on the correct encoding of the "role" attribute. 3b. Support for a <body> element that may occur one or more times within <html>. As an alternative to <backm> and <frontm> elements, we might pursue encapsulating the legal instrument in its own <body> element, with an appropriate value supplied for its "role" attribute to indicate the type of legal instrument. The front matter and back matter sections would be similarly labelled using the "role" attribute. 3c. Support for a <clause> element, relegating the <section> element to the role of distinguishing between the logical "parts" of the physical document, and also between certain subsections and the clause area of a document, e.g., signature areas represented as <section role='SignatureBlock'/>. The choice of "names" for these items is what is crucial. Many people would readily understand a "section" as being a major document division, and "clause" being a container of grammatical paragraphs. It would be enormously useful for the W3C to standardize the name of the element so that we can use the "role" attribute to indicate the type of clause, eg IntegrationClause, which I think is a more intuitive use than a value of "Clause" in the "role" attribute. 4. Support for defining the "role" attribute as a QNAMES, not a QNAME, attribute. It is an unnecessary constraint, and burden, on standards groups to be able to attach only one "name" to a clause, particularly in light of CSS support for multi-token attributes. 5. Support for standardizing two "links" between an XHTML 2.0 document and (1) its Dublin Core metadata and (2) one or more RDF metadata documents. Much if not all of the process/workflow metadata we have now specified in our scenarios will be located in an RDF document -- it is senseless from several perspectives, under most circumstances, to embed such metadata into the legal instrument itself. The RDF document will clearly also include LegalXML elements that indicate the "semantics" of the legal instrument. 6. Support for re-factoring certain rarely-used XHTML 2.0 inline elements into a module that is not required for Host Language conformance. This seems an important issue to Jason at least.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]