Re: OMITTAG specifications in element declarations

At 11:52 PM 11/2/96 EST, lee@sq.com wrote:

>> Consider the following scenario:  You deal with a lot of documents
>> that at some point in their lives use omittag in their processing,
>> so you need a DTD that can be used with "OMITTAG YES".  At some point
>> in the processing, you normalize the documents.  Thereafter, the
>> documents can be processed with "OMITTAG YES" or "OMITTAG NO".
>[...]
>> You are saying that under these circumstances it's better to have
>> to maintain two versions of your DTD.  I say, nonsense!
>
>That is a good point.
>
>However, if you then convert your documents to XML, you will need a
>new DTD for the XML documents, as described above.
>Use software to produce the DTD, not hacks.
>You might as well say that XML parsers should understand
>parmeter entity definitions and & in content models, but ignore them.
>
>So I still think there is no good reason to litter XML DTDs with
>- and O tokens.

I agree. It might be worthwhile to point out that a subset (as XML is 
canonically cast w.r.t SGML) will fail backward compatibility by force, 
because there will be old (i.e. existing) documents that new (XML) systems 
will not be able to handle as-is. Some sort of out-conversion will be 
needed in general, and I agree with Lee that hacks are not the way to do 
that. OTOH, the forward compatibility test, whether old (SGML) systems can
handle new (XML) documents, hinges -- at least here -- on the fact that 
OMITTAG will be NO for the XML docs, so the SGML system won't need the
minimization parameters anyway in the relevant DTDs.

Occam's Razor (or is it Caveat Clutter?) says nuke 'em.


Arjun
--
"Features whose purpose is to cause errors should be removed." -- Erik Naggum

Received on Sunday, 3 November 1996 01:02:47 UTC