W3C home > Mailing lists > Public > public-html@w3.org > November 2009

Re: XHTML character entity support

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 11 Nov 2009 16:25:14 +0200
Cc: public-html@w3.org, public-xml-core-wg@w3.org
Message-Id: <3D9ACE2C-1D76-4902-BB07-87538CB8AC2E@iki.fi>
To: David Carlisle <davidc@nag.co.uk>
On Nov 11, 2009, at 16:05, David Carlisle wrote:

>> Using something that doesn't name an old version of MathML gets you
>> the YSoD in shipped Gecko 
> well if your document is targetting shipped gecko then you will restrict to
> mathml2 (and only some parts of html5) anyway so using a mathml2 doctype
> would be pretty reasonable.

Indeed, you wouldn't be able to reliably use entities that weren't also in MathML 2 in existing Gecko installations even if a future Gecko refreshed the entity list the public id points to.

> But (whatever Mozilla's actual plans, which
> aren't directly relevant to the spec) the spec should be written
> assuming that rendering engines will appear sometime in the future that
> implement html5 and mathml3.

HTML5 is concerned with how new stuff degrades in existing browsers.

>> It doesn't make the document invalid if you use a non-legacy
>> validation mechanism and turn off DTD validation. (To pre-empt
>> concerns like this, Validator.nu doesn't let you enable DTD validation
>> even as an option.) 
> Saying that it's OK to make the XML usage fragile and weird because
> people can use non xml tools doesn't really address the problem.

XML is fragile *by design*! (Draconian error handling and making external entity loading permitted but optional. The real fix would be to move to XML5 with robust error recovery and no external entities.)

> but my suggestion would be to arrange the effective entity
> resolver such that the end user never really needs to know this id at
> all and (in a browser-like context for application/xhtml+xml) always
> unconditionally act as if this doctype had  been used rather than
> manintaining a special list of doctype id that trigger this.

Then you'd be creating a new almost-XML language that wouldn't work in vanilla XML tools no matter what catalog hacks were in place.

> If you
> freeze a special list then (as noted above) it becomes more and more
> disconected from reality as languages are revised, or the browser has to
> keep making the list longer, neither of which is ideal.

The real fix is 
 1) The Math WG stops minting new entities.
And then
 2) XML Core specifies XML5 that among other things predefines all the MathML entities.

Henri Sivonen
Received on Wednesday, 11 November 2009 14:25:49 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:03 UTC