Re: OMITTAG specifications in element declarations
Dave Peterson (after misunderstanding my posting) raises the
situation where you process documents to remove omitted tags
and then continue to use the same DTD but with OMITTAG set to NO.
He then says that he wants to use the same DTD with XML, and therefore
XML should ignore the omittag minimization parameters.
This argument only works if XML can also ignore all the other SGML
features you might be using -- USEMAP, CONREF, CONCUR, LINK, marked
sections, & in model groups, inclusions and exclusions, mixed content
models with ",", and all the other things not permitted in XML.
So I don't buy it.
> <firstname.lastname@example.org> recently wrote:
>> It is a red herring to say that putting [omitted tag specs] in XML would
>> help compatibility: if you have OMITTAG YES in your DTD, you need to run
>> SPAM or otherwise ensure that there are no omitted tags.
> You're raising the red herring, Lee. If the SGML declaration says OMITTAG
> NO, then you can't omit tags.
I am perfectly well aware of that!
> "OMITTAG YES" is not what's under discussion;
> that's a closed issue--not permitted for XML.
You misunderstand me completely. I am aware of that too.
I am talking about the case where you have been using an SGML declaration
that has OMITTAG YES, and the ommitted minimization parameters in the DTD
(no, I don't need a lecture about where they go) and therefore you may have
documents that omit tags. You might not. In migrating to XML, you must
remove all traces of OMITTAG from your documents. You might as well also
remove all traces of OMITTAG from your DTD, at the same time as you flatten
parameter entites from your content models, remove & from model groups,
remove inclusions and exclusions, flatten external entities, and remove
Then edit your instances to make them conform to the new simpler DTD,
removing all SDATA entities and replacing them Unicode character
references, as well as inserting all omitted tags, removing all
instances of NET tags, null tags, and other minimisation.
Probably there will be programs to do this. Maybe an SP application?
Maybe the same program will transform your DTD.
It's not worth thinking about people with complex DTDs (TEI, DOCBOOK,
IBMIDDOC, DECBOOK, CALS, ATA, AAP/ISO12083) using exactly the same
unedited DTD with XML. It can't happen. In any case, the goal of
XML is surely not to take existing SGML users away from SGML and
towards XML, but to win hordes of new people to the burgeoning SGML camp,
via a more gentle path than the mountain pass that you, Eve, I and others
have traversed. Well, you and Charles were in the party that cut the steps.
[explanation of "omitted tag specification parameter" deleted]
>> XML applictions won't handle your text otherwise, so it doesn't
>> matter if they will handle the DTD or not.
> Nonsense. in SGML tags _never_ must be omitted just because they are
> _permitted_ to be omitted. No one is suggesting that XML documents
> might have omitted tags.
Including me. It isn't nonsense, actually. If you have existing
SGML documents with omitted tags, they won't work with XML parsers.
And if you have OMITTAG YES in yout SGML declaration, you can't easily
tell whether you have such elements or not, in general, unless you've
been using InContext, Author/Editor, Adept, or some other software that
will put all the tagsin for you. But in that case, there's no need to
use OMITTAG in the first place, and hence you don't need to have the
ommitted tag minimization parameters in the DTD.
> 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.