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

1. Support for the <section> element, with a request to specifically describe
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>

	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,

	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]