[legalxml-econtracts] Pruning XHTML2 for eContracts - draft 2

[Jason Harrop <jharrop@speedlegal.com>]

Hi all

Having discussed at some length with John McClure whether or not we need 
to prune XHTML, it became clear that the paper I previously posted had 
focused only on ameliorating the authoring difficulties.  It didn't 
identify the problems that (in the absence of pruning) we are (imho) 
foisting on developers of eContract applications.

The amended draft attached describes this second class of problems which 
we ought to address. For convenience, I've pasted the most relevant 
portion below.

This draft also attempts to assess whether pruning costs us any of the 
advantages which XHTML is thought to provide.  I think those advantages 
  are substantially retained.

I hope the TC is or can be persuaded that "pruning" is essential, if we 
are to use XHTML successfully.

thanks,

Jason

-----------------------

These unnecessary and inappropriate elements and attributes also make 
things harder for software developers and integrators who may wish to 
provide tools or support for our standard.

For example:
- it will take more effort to create an easy to use XML editor, since 
you have to programmatically guide the user along the correct path 
(since the DTD invites them to stray), and programmatically hide things 
which shouldn't be there;
- it will take more effort to create styled output, since many more 
structures are possible.  Some of these structures probably look 
identical, and its not clear how others should appear;
- conversion from Word to XML may be more difficult, since there are 
more choices to be made for what you are converting to;
- other custom software which parses eContracts XML and does something 
with it would also need to handle more cases than would otherwise be 
necessary.

How is a developer likely to handle this challenge?

Either they use a simplified DTD which does not have these problems, and 
ensure all the content conforms to this, or they accept the additional 
complexity.  I personally would opt for the former (ie create my own 
simplified DTD).  However, the problem with using a simplified DTD is 
handling incoming content from a third party who uses the full Host 
Language DTD, since if this content does anything which isn't permitted 
by the simplified DTD, then it will need to be converted (and it is 
unlikely this can be done transparently and automically with 100% 
satisfactory results).

Further, if the TC retains these unnecessary and inappropriate elements 
/ attributes / content models, the TC also creates extra work for 
itself, since it will need to prepare guidelines as to how the DTD 
should be used.  For example, “The grammar allows #PCDATA in a <section> 
element.  This is appropriate where ...” or “Although the grammar allows 
#PCDATA in a <section> element, it is not recommended that this be done” .

In short, it is the proper role of the TC to promulgate a DTD which is 
general enough to represent content which is appropriate for contracts 
(or possibly contracts and other business documents), but no looser. 
Anything looser imposes unnecessary burdens on users and software 
developers alike, and amounts to a failure on the part of the TC.

PruningXHTML2.doc