Considering that

 * The XML spec doesn't guarantee that an external DTD is processed,
which makes DTDs inherently unreliable in a system where the author
doesn't control the clients (like on the Web).

 * When authors do use character entities, authors need the entities to
work reliably--certainly not causing the YSoD.

 * Legacy pages assume the public ids in Gecko's current DTD catalog to
map to something that makes character entities work. This has already
caused grief for Opera and Safari.

 * Making browsers fetch DTDs is not feasible, so the set of DTDs that
"work" cannot really be dynamic.

...I think it follows that it is bad if the availability of character
entities with a given DTD public id is not 100% predictable across
browsers and browsers versions.

The only way for the mapping to be predictable across browsers and
browser versions is freezing the mappings and standardizing them as a
grandfathered legacy, to rely on straight UTF-8 for anything that the
frozen mappings don't cover and to migrate to DTDless XML 1.0 over time
and perhaps later to XML5 if that ever goes somewhere.

I, therefore, suggest freezing the set of magic public ids Gecko knows
about at Firefox 3, documenting Gecko's magic pseudo-DTD catalog and
offering the documentation to the W3C HTML WG and WHATWG for suggested
inclusion as part of UA requirements for processing XHTML5.

Opinions?

Background:
https://bugzilla.mozilla.org/show_bug.cgi?id=289938#c16
https://bugzilla.mozilla.org/show_bug.cgi?id=289938#c20
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
http://hsivonen.iki.fi/no-dtd/

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

This sounds like a fine idea. The only thing I'd add is that future web
specs might increase this list. For example it would have made sense for
the MathML and SVG specs to state that in order to implement the spec
the UA should add a particular DTD to its DTD catalog.

/ Jonas

In article <ktqdnYczc_IT2nXanZ2dnUVZ_rLin...@mozilla.org>,
 Jonas Sicking <jo...@sicking.cc> wrote:

The crux of my suggestion was *never* to add new public ids. Concretely,
this would mean refusing to recognize any public id that MathML 3 might
define and preferably convincing the WG not to define any. (The SVG WG
has already ditched DTDs.)

Consider the two scenarios for MathML 3:

1) A future Firefox doesn't add MathML 3 public ids. Authors will use a
MathML 2 public id to import entities or, more likely, use UTF-8 or
numeric character references. These will probably be generated
automatically by MathML authoring tools at that point. The resulting
pages degrade gracefully in older Firefox releases.

2) A future Firefox adds MathML 3 public ids. Authors use the new public
ids and reference character entities--even if only "old" ones that
existed in the MathML 2 DTD. The user experience in older Firefox
releases is about as ungraceful it can get short of crashing: the YSoD.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/