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?? :-) :-)

No, but a lot of DTDs are industry DTDs where the maintainers have
little control or influence over how documents are created.  XML
may require all tags to be present, but I know an awful lot of
people who still key in tags by hand (Allah knows why! :-) and take
advantage of tag omission.  Is it an acceptable process model to 
let them do this and then normalize into XML?

>> 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.

What I mean is that the SGML declaration has some settings related
to DTDs (e.g. NAMELEN), and some related to instances.  You can't
craft an SGML declaration solely on the basis of what your DTD
needs, and therefore the crafting of the SGML declaration might be
in the hands of people who didn't write the DTD.  OMITTAG affects
both the instance's behavior and the DTD's element declarations.
OMITTAG YES requires the tag omission fields; OMITTAG NO *allows*
them, precisely (I assume) so you can go back and forth on this
setting without having to change the DTD.

Of course, XML doesn't even have SGML declarations, but full SGML
does.  We've disallowed a bunch of DTD behavior already, but none
of it has a corresponding setting in the SGML declaration; if we
were to provide an "XML SGML declaration" as part of the spec (which
I think is a good idea), and it said OMITTAG NO, it would still
imply that the tag omission fields are allowed.

>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.

There's no "standard SGML declaration," just reference and core
concrete syntaxes.  (ADEPT uses a default decl internally, which
you can change, save, etc.)  I can't imagine whipping up an SGML
declaration every time; I always start with an existing one!

>> 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?

The ERB is still discussing parameter entities, I believe, and the
prognosis looks good.  (Would it change your mind if they definitely
were allowed?)  And NAMECASE GENERAL is still on the block.

>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.

I disagree that DTD simplification provides most of the benefits
of XML; I believe it affects validation software more than it
affects the majority of users.  (The general simplification and
normalization of the language as a whole -- DTDs and instances --
does help SGML's teachability and parsability quotients, which are
very important.)

There are still a lot of questions about how SGML and the "XML
application profile" will interact, especially in the short term
(when there will be no such thing as "XML software" yet).  I guess
I'm still an SGML conservative on the OMITTAG issue, preferring to
allow more existing DTDs to be used as they are.