marked section in new HTML DTDsTerry Allen <firstname.lastname@example.org>
Date: Sat, 24 Sep 94 13:56:11 EDT
From: Terry Allen <email@example.com>
To: Multiple recipients of list <firstname.lastname@example.org>
Subject: marked section in new HTML DTDs
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
I've been working out the combinations of marked sections in Dan's
set of 3 new DTDs, which leads to a discussion of Recommended
and Deprecated features. All aboard!
- HTML.Recommended excludes HTML.Deprecated, so there are only
two branches there (assuming that only HTML.Recommended
is to be switched; otherwise you could switch them both
off and have three branches).
- HTML.Forms is set to INCLUDE, and is to be switched by use
of html-1.dtd, whose sole purpose is to switch it off.
(It also defines an %html; parameter entity that is unused
elsewhere but whose value, "-//IETF//DTD HTML//EN//2.0",
matches the value of %HTML.Version in html.dtd. It appears
that this is supposed to invoke the html.dtd, but the FPIs
- HTML.Highlighting is set to INCLUDE, but is not toggled anywhere
else. In the previous DTDs, some of this was level 1 stuff,
and there was a Proposed version of it. Is this entity
needed? was it meant to be toggled in html-0.dtd? You
can't set it to IGNORE, or you lose much of the inline
markup; in Highlighting.html it says that the ability
to render this highlighting is a Level 1 requirement.
However, html-0.dtd does not appear to invoke either of
the other DTDs, and includes IMG, which Specification.html
says is not required in Level 0. The sole difference here
seems to be that ALT is required in Level 0 and not in
the other Levels. This has been questioned, with good
Eventually we want to require ALT so as to aid the text-
impaired, but there must be scads of docs that don't
have it now (thus is properly IMPLIED in the other two
DTDs). If the idea is that Level 0 is so mingy that it can't
render IMG and so the user must rely on ALT, then we're
talking about imposing new requirements on authors.
I like the explanation that the html-0.dtd tells authors
what they ought to do to reach all audiences through
all interfaces, but then this is really a DTD for writers,
and not for use by browser developers seeking to develop
Level 0 compliance---what does it mean to tell them that
they can count on ALT being there (it's REQUIRED, after
all) when they really can't? anyway ...
if HTML.Highlighting and HTML.Forms may be toggled independently
of each other, there are of course 4 possibilities; neither
is toggled by HTML.Recommended or HTML.Forms, so that makes 8
if we forget about html-0.dtd and suppress the entity
HTML.Highlighting, liberating its contents, then there are only
4 possiblities (Recommended/Deprecated//with Forms/without Forms).
Of these, we certainly want to save the difference between having
Forms and not having them (expressed by the difference between
using html.dtd and html-1.dtd).
As we are documenting current practice, I see no point in having
HTML.Recommended and HTML.Deprecated. I think they would be a
fine basis for starting consideration of 2.1, however. If we
could decide what to keep in html.dtd and get rid of these two,
we'd have two DTDs, one with Forms and one without, corresponding
to Level 1 and Level 2, which is pretty much what's desired.
Then html-0.dtd is just a DTD on its own, with somewhat different
aims (okay by me).
Of the Recommended items,
- linkName is a good idea, but could be left to 2.1
- I object again to restricting A.content to %text;.
I want to be able to wrap as a hot spot one
or more paras, perhaps including heads, and
so on. There is no requirement that a link
be only an inline animal.
- body.content I like, but would be happy to defer to
- address.content might be left for 2.1. I imagine
there will be requests for elaborating ADDRESS,
- head.nextid could go in now; isn't this current
practice? or is the point that it's not
Of the Deprecated items,
- preformatted involves sunsetting XMP and LISTING;
desireable though this may be, let's take
it up in 2.1.
- literal (being CDATA for XMP, LISTING, and PRE)
is really difficult, besides being weird.
I have never done anything with DATATAG,
but if you could use it to insert CDATA
marked sections within these elements, it
might work (although involving some SGML
tomfoolery that is probably the kind of thing
TimBL urged us to avoid). Just a suggestion.
- html.content is like body.content (getting rid of
free-floating text); I like the restriction
but think it goes in 2.1.
And I think that's the whole set, much cleaner than before
(thanks, Dan). I think this is my stop.
Terry Allen (email@example.com) Editor, Digital Media Group
O'Reilly & Associates, Inc. Sebastopol, Calif., 95472