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

["Mary McRae" <mary@office-xml.com>]

This is a test to see if I can actually post to this list ... I don't think
I can for something like 60 days...

Mary

Mary P McRae
Senior Vice President and Principal XML Technologist
DMSi
email: mmcrae@dmsi-world.com
web: www.dmsi-world.com
cell: 603.557.7985


> -----Original Message-----
> From: Jason Harrop [mailto:jharrop@speedlegal.com] 
> Sent: Tuesday, January 27, 2004 5:48 AM
> To: Legalxml-Econtracts
> Subject: [legalxml-econtracts] Pruning XHTML2 for eContracts - draft 2
> 
> 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.
>