W3C home > Mailing lists > Public > www-math@w3.org > April 2008

Re: MathML entities don't degrade gracefully

From: David Carlisle <davidc@nag.co.uk>
Date: Thu, 24 Apr 2008 17:41:25 +0100
Message-Id: <200804241641.m3OGfPAC014768@quetzal.nag.co.uk>
To: hsivonen@iki.fi
CC: public-html@w3.org, www-math@w3.org


> As for application/xhtml+xml, the situation is even worse.

The fact that using an entity that's not defined is a wellformedness
error that probably causes the entire document to be rejected is, hmm
problematic, and the main reason why we try to keep the set of mathml
entity names unchanged, even if we occasionally change the definitions
to take account of additions to Unicode. The XML spec does leave an
escape clause that if the document references a DTD and the application
does not fetch the dtd then the error need not be fatal (thus allowing
Opera's current behaviour). Although most XML parsers (and certainly
anything using xslt/xpath/xquery) have to reject the document as the
xpath data model doesn't support undefined entities.

Going forward it has often been suggested that a possible way to
alleviate this problem is just for everyone to use the same set of
entities always, and putting them all in html5 would be a move in that
direction, although behaviour on existing systems is as you describe.

So it's really a matter of future benefits against bad fallback
behaviour on existing systems.

As I said to Ian earlier I think the most important thing is that the
definitions agree where they use the same name (and I think html5 and
mathml3 drafts do now agree). Whether html5 should include all the names
is less clear. It has some advantages and I would not argue against it,
but it also has some disadvantages and I wouldn't argue too strongly for
them to be kept either.

The MathML3 draft has modified all the example fragments of mathml code
never to use the entity form and always to use numeric character
references (together with a comment with the unicode name) to try to
wean people off entities.

(Personal response)
Received on Thursday, 24 April 2008 16:43:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:40 UTC