Re: OMITTAG specifications in element declarations
> The difference between OMITTAG and SHORTREF is that pretty much *every*
> DTD today includes the OMITTAG field,
I would dispute that. Certainly we (at SQ) discourage its use. One reason
is that many SGML tools give clearer error messages without it.
Another is that it's pointless if you're using SGML-aware software, and
that's the business we (SQ) are in. Perhaps most ArborText customers
prefer to key their text in using vi or notepad?? :-) :-)
> even if just "- -", partly because
> the SGML declaration (where OMITTAG is set to YES or NO) is a component of
> SGML documents as a whole, and DTDs technically don't automatically
> "come with" their own SGML declaration.
I'm not sure what this means. Every SGML document has an SGML declaration,
and you always have to supply it, so yes, DTDs darned well ought to come
with their own SGML declaration if they need one.
It's true that I sometimes find people starting with the CALS declaration
and editing it, and I usually suggest that they stop doing that and
start with the standard one. You can get Author/Editor to save one for
you by checking "include SGML declaration" when you save your SGML.
> For me, this definitely comes under the heading of deciding whether or
> not to punish existing SGML users.
I don't think it is any worse in that regard than not supporting
parameter entities, or than having NAMECASE NO. Having no OMITTAG
support in XML means that you'll have to change all those documents
anyway, and what better way to check that than with an SGML declaration
with OMITTAG set to NO? And what better way to make sure you've done
that than with a DTD without the tag omissibility thingies?
If most existing SGML DTDs work unchanged in XML, it seems to me that
we probably haven't simplified SGML enough to make any difference. If
most existing implementations use only the features of SGML that we
deem essential for XML, it's not clear to me that giving a name to that
set of features will actually encourage many more people to write
software than have already done so.
So I think we have to be brutal.
But it is good that you've pointed this out.