Re: [legalxml-econtracts] re: Agenda for 7/13 meeting

[Jason Harrop <jharrop@speedlegal.com>]

Please see comments inline.

John McClure wrote:
> Their view is that much needs to be done - tables, signatures, parties, dates,
> headers, footers, preambles, front matter and back matter, and even clause
> numbering. That is alot !!! IF AND ONLY IF one is aiming to re-craft XHTML
> rather than to adopt XHTML 2.0 as much as technically possible. 

I said tables, signatures, headers/footers, and clause numbering needs 
to be done.

I didn't say "preambles, front matter and back matter"

There isn't a lot of work in tables, signatures, headers/footers, and 
clause numbering, and work in those areas needs to be done whether one 
does it my way or yours:

- tables, i think we all agree XHTML <table> should be used.  But, the 
TC needs to provide guidance as to how to specify borders, shading etc. 
ie should a CSS dependency be introduced?

- signatures: this can be treated as a standalone piece.  Whether we do 
it your way or some other way, the work needs to be done.  And to do the 
work, the TC should first say "here are examples of the signatures we'd 
like to be able to represent, and here are our expectations about the 
effort an author should go to to input them"

- headers/footers: the TC needs to provide guidance as to whether these 
are in the XML or the stylesheet; the rest is easy.

- clause numbering: this needs to be thought through a bit.  one issue 
is in exchange between applications, when is an application allowed to 
renumber?  This is tied in to cross references.

> My point is
> this: given their methodology then Jason is plainly correct that more thought
> about a contract schema is required but, by adjusting the methodology, the
> result could be entirely different. 

I think that whether one uses your adjustments to XHTML2, or the ones 
Peter and I tend to favour, the same issues need to be addressed.  It is 
the solution which looks different.

It is the issues the TC needs to provide guidance on; it is from that 
guidance that the best solution will flow.

And, in my opinion, could yield an
> implicitly superior product.

> 
> For tables, I recommended using XHTML <table> elements.

	(Yes, but questions remain as to how to do borders, shading)

> For signatures, I recommended one container <area> element.

	(Introducing a new element called <area> is one of a variety of 
possible models)

> For parties, I recommended identifying them in an associated RDF file.

	(This is using a sledgehammmer to crack a wallnut.  It is imposing 
considerable expense in terms of tools and training, when a far simpler 
solution is possible)

> For dates, I recommended placing all dates into an associated RDF file.

	(Out of scope of structural)

> For footers and headers, I recommended for each, an <area> element.

	(TC needs to provide guidance as to whether these are in the document 
or in the stylesheet)

> For front/back matter, I recommended for each item a container <div>.

	(That is one approach.  The one Peter and I will suggest uses named 
containers.  These could be mapped to <div> for a plain vanilla XHTML 
document)

> For clause numbering, I thought we agreed <nr> contains just plain text.
> For captioned tables/images, I recommended container <area> elements.

	(Not sure that this addition is necessary)

> 
> So, my recommendation to Jason and Peter was this: (1) add a few new elements to
> XHTML, i.e., 3 or 4 new elements (2) subtract a few old elements from XHTML (3)
> impose constraints on the use of retained XHTML elements (4) use the XHTML
> 'class' attribute to identify the type of use for the element and 

Not too many differences when expressed at this level...

(5) place all
> 'semantic' information about the contract, eg parties and dates, into an
> associated (linked) RDF file that has a decidedly Dublin Core orientation.

This we probably disagree on, but the semantic question is exactly what 
isn't structural, so its out of scope.

I think its pretty clear that the 2 approaches to the high level 
containers ought to be compared, and the TC can choose the one it likes.

That will be much easier if you can stay quiet about the orthogonal 
issues discussed in this email (headers/footers, areas, signatures, 
tables) for a little while, and raise them at the appropriate point in 
the process.

Jason