RE: [legalxml-econtracts] Another clause model proposal

["John McClure" <jmcclure@hypergrove.com>]

Hi Peter,
Wow, very impressive document. I would like to understand better its differences
from Jason's model, but my gut reaction is that you have proposed a most
thoughtful clause model that I can support. I'm hopeful though that we can
discuss tomorrow the news you kindly bring about XHTML 2.0 -- a draft I admit I
have not been following. Maybe you could share your thoughts about these
counter-arguments to your concerns about our adoption of XHTML 2.0 as the clause
model, as you outline them in Section 6?

	(a) Proposed XHTML 2.0 is still not a satisfactory structural model for
	the widespread markup of contract documents. A complete, simple
	structural model is still required.

		A few examples here would help me understand how 2.0 is
		neither complete nor simple for authoring purposes.

	(b) Developments of XHTML 2.0 take it in a direction that would make it
	comparatively easy to translate from the clause model to XHTML 2.0.

		Hmm, this sounds like an argument *for*  2.0, suggesting that
		2.0 provides the functionality that we need.

	(c) Proposed XHTML 2.0 is only a draft and it is not clear what direction
	it will take. The Technical Committee needs a schema for contract
	documents that will provide a stable platform for development of
	semantic markup layers and as a means to provide potential users
	with a comprehensive framework for the markup of contract documents.

		Yes you're right, but all W3 specs go through an extensive
		draft process. It seems to me inarguable that XHTML 2.0 will be
		adopted by the W3, and will indeed be deployed internationally.
		As to semantic markup layers, please see below.

	(d) Ignoring its limitations, the proposed XHTML 2.0 provides little extra
	functionality than the basic clause model for contracts markup. Much of
	the work is already done. If the basic clause model is adopted by the
	Technical Committee, it is still necessary to undertake extensive schema
	development. It will be easier to develop this on a platform under the
	Technical Committee’s control, particularly in the first instance.

		I happily note the XHTML 2.0 spec will incorporate references
		to RDF metadata applicable to the XHMTL document  (see
		http://www.w3.org/TR/xhtml2/mod-meta.html#sec_13.1.2.)
		The view, no doubt, is that the extensive schema development
		to which you refer here and above yields elements that are to
		be placed into the RDF description of the XHTML file, *not* into
		the XHTML markup itself. So, there is still plenty left for us to do,
		*all* of it still under our control.

Anyway, thanks again for bringing XHTML 2.0 to the table -- it means at least
that I now withdraw the notion of embedding <lgl:Block> elements within markup
of an XHTML (presentation) datastream contained by an <Instrument> envelope,
since 2.0's <section> element serves the same objective: to link to (or
describe) positional content without referencing id values. There are certainly
other aspects of my proposed Technical Requirements that I'll review in light of
the XHTML 2.0 draft. Maybe Modular XHTML will allow us to avoid defining an
<Instrument> element altogether.

Regards,
John