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:
web: www.dmsi-world.com
cell: 603.557.7985
> -----Original Message-----
> From: Jason Harrop [mailto:]
> 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.
>
