Re: marked section in new HTML DTDs
Terry Allen <terry@ora.com>
Date: Sun, 25 Sep 94 20:17:26 EDT
Message-id: <199409260016.RAA05084@rock>
Reply-To: terry@ora.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Terry Allen <terry@ora.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: marked section in new HTML DTDs
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
| The idea is that there are three branches: you can validate that your
| document is standard html, or by setting HTML.Deprecated to "IGNORE,"
| you can validate that your document uses no deprecated idioms, or by
| setting HTML.Recommended to "INCLUDE" you can validate that your
| document uses only recommended idioms.
| I have had comments from at least two HTML editor implementors that
| said they liked having the HTML.Recommended distinction. I think
| it's useful.
Okay so far; if we were to stay with this model, there should be a
comment in the DTD about the effect
of toggling. Implementors are liable to be tripped up by the
reverse order of priority that SGML assigns to redefinitions, and
they need to be told which toggles they should keep their hands off.
It would also be possible to wrap up all the toggles as I did in
3in1.dtd.
| > (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
| > need synchronization.
| They seem to be perfectly in sync to me:
| connolly@austin2 ../html-spec[505] grep -n 'DTD HTML//' html-1.dtd html.dtd
| html-1.dtd:29:<!ENTITY % html PUBLIC "-//IETF//DTD HTML//EN//2.0">
But that should refer to an FPI, and the FPI of the target (html.dtd)
is indicated in the usage note to be (l. 18):
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
whereas, as you note, the version in html.dtd is:
| html.dtd:14: "-//IETF//DTD HTML//EN//2.0"
those two lines need synching.
| > - HTML.Highlighting is set to INCLUDE, but is not toggled anywhere
| > else.
| Except for:
| html-0.dtd:30:<!ENTITY % HTML.Highlighting "IGNORE">
Not in the version I retrieved by using the URL embedded in your
announcement:
$Id: html-0.dtd,v 1.7 1994/07/20 16:24:27 connolly Exp $
in which l. 30 is
<!ENTITY % HTML.Prescriptive "IGNORE"
It appears (below) that I have a mismatched set of DTDs.
| > Is this entity
| > needed? was it meant to be toggled in html-0.dtd?
| I think so, and yes.
It isn't in my version, which must be a wrong 'un.
| > However, html-0.dtd does not appear to invoke either of
| > the other DTDs, and includes IMG,
| Did you get some funky version of html-0.dtd? It's right there:
Apparently so.
| The version is $Id: html-0.dtd,v 1.7 1994/07/20 16:24:27 connolly Exp $
Exactly what mine says. I'll send it to you separately, Dan.
| > 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
| > reason.
| > 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
| So they're not level 0 documents. That's the point.
| > (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.
| Bingo.
Well, then, we can't guarantee that any existing document is Level 0,
which I thought was supposed to be the lowest level of conformance;
why should there be new requirements in Level 0, when Levels 1 and 2
are progessively more complex, and yet document current practice?
Are there actually Level 0 browsers, which can't do inline emphasis
in any way but which require that ALT values be present?
| The question is: how many possibilities get public identifiers?
| They can write:
| <!docytpe HTML PUBLIC "-//IETF//DTD HTML Level 0//EN">
| which is useful at least for local batch-validation.
| Currently, there are three public identifiers: level 0, level 1, and
| level 2.
Yes, but you allow people to toggle Recommended, which gives
at least two more possibilities (Levels 1 and 2 with/without R).
Developers will want to say they're "HTML conformant," and what
that means will be obscure if it means more than Level 0/1/2.
And there are additional possibilities that need to be warned
against, lest we hear, "uh, well, I do HTML Level 2 with
both Recommended and Deprecated---I want to cover all the bases."
| >As we are documenting current practice, I see no point in having
| >HTML.Recommended and HTML.Deprecated.
| They're in there to support editing of new documents. We may
| decide that this is not a compelling reason, but it's more than
| "no point."
I am not compelled to include these in the html.dtd. We are
documenting current practice. That's
all we can do at this stage, and we want to get it done with.
Immediately thereafter we can take up all these quite good
recommendations. But right now we need a clean spec and
we are not in position to answer the question you rightly
pose in another post:
>So how do we gracefully deploy changes in HTML?
| >Of the Recommended items,
| > - linkName is a good idea, but could be left to 2.1
| That's why it's only recommended.
[etc]
I'd like to deal with this question differently, and make it formal.
>>>I propose that we remove these Recommended and Deprecated sections
from the DTD we call 2.0 (for which we want approval by Dec or
earlier), and use the present html.dtd as the basis for 2.1;
we could even distribute it at the same time, as a device to obtain
comment and support editing of new docs.
Your work in testing real docs to figure out vanilla, Recommended,
and Deprecated is priceless, Dan, but it seems to me that only
vanilla applies to this stage.
| > - 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.
| So we should support ID attributes on lots of elements as link
| targets. Or support HyTime dataloc links ("link to work 3-8 of
| paragraph 7").
ID atts don't lead to the same solution, and I decline to try to
persuade WWWers to do HyTime. I want one anchor to be capable of
encompassing more than one IDable element, e.g.,
<html><head><title>fo</title></head><body>
<A HREF="http://foo.bar.com/">
<H1>some text</H1>
<P>foo
</A>
</body><html>
which works *right now* and should continue to do so.
| > There is no requirement that a link
| > be only an inline animal.
| There is in a lot of conversion software. There is in HTML+. Plus, it
| keeps parsing and processing simple. "HTML is cheap technology."
It's just too useful to want to give up for those reasons.
| > - head.nextid could go in now; isn't this current
| > practice? or is the point that it's not
| > supported?
| The point is that it's not recommended to use NEXTID nor to
| rely on it. The right thing to do is to look at all the
| link names and choose something that's distinct from them.
Ah. I see, it's negated it in Recommended, rather than included
in Deprecated.
The apparently faulty DTD to follow.
--
Terry Allen (terry@ora.com) Editor, Digital Media Group
O'Reilly & Associates, Inc. Sebastopol, Calif., 95472