> In message <9506030109.AA16555@trystero.art.com>, Joe English writes:
> >> > [joe@art.com wrote:]
> >> > Calling them "deprecated" is not strong enough for me.
> >> > They were "obsolete" as of May 31, and I *strongly urge* that
> >> > they stay that way until HTML 2.1, when they should
> >> > be eliminated altogether.
>
> Before this change (moving XMP/LISTING from appendix to normative but
> deprecated), the DTD was inconsistent with the prose of the spec. So
> my choices were: change the DTD, or change the prose.
I see your point.
However, I still object to calling them merely "deprecated" --
that puts XMP and LISTING in the same category as constructs
like null end-tags and marked sections, whose use is only
discouraged "at least until such time as support for them is widely
deployed."
There needs to be a more clear distinction between "stuff you shouldn't
use because lots of browsers don't get it right *yet*" and
"stuff you shouldn't use because it'll eventually be taken
out of the spec" in the prose. I liked the word "obsolete"
to describe the latter category, and would even be happy
with "deprecated" IF some other term (maybe "discouraged"?)
were used to describe constructs in the former category.
(The DTD does a good job of making this distinction,
but most users don't or can't read the DTD, the majority
don't validate against it, and of those that do only a
few use strict mode.)
> For example, if you built the search service that you mentioned, you
> _would_ have to deal with XMP and LISTING somehow: fact of life. If
> the 2.0 spec said they were obsolete, you'd have an argument for
> treating them as a failure mode.
But I already have an argument for doing so: by their
very nature, my hypothetical search engine cannot possibly
handle them properly.
My concern is that if they are not clearly marked
as "obsolete", or better yet, pushed to the back of the spec,
more authors will use them, check with Netscape, see that
they work, and say "Hey! Support has been widely deployed.
Guess it's safe now." Then my search engine will have to
deal with CDATA declared content all the more frequently,
the body of legacy documents will grow, and XMP and LISTING
will be around forever.
> Do you think that would make your
> customers happy? Imagine this sequence:
>
> User searches database like lycos with this software,
> search engine returns "error: can't do highlighting: invalid document"
> user complains to service provider
> servide provider complains to search engine vendor
> search engine vendor says "we just coded to the spec"
> Nobody is happy.
The scenario I envision is more like:
as above, except that the search engine makes
a best effort attempt at highlighting instead of
failing outright; service provider complains to
search engine vendor; search engine vendor
says "sorry, it just plain doesn't work with <XMP>
and <LISTING>. Guess why they're obsolete?"
> So (1) I believe changes to the DTD at this point are horrendously
> expensive,
No argument here -- <XMP> and <LISTING> need to stay
in the DTD so implementors know what to expect.
> and (2) I think deprecating, rather than obsoleting
> XMP/LISTING is actually the Right Thing To Do at this point.
Only if it is made *very clear* in the prose section
that there are fundamental problems with <XMP> and <LISTING>,
and that they are deprecated for reasons other than
historically inconsistent implementations.
--Joe English
joe@art.com