>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.
