- From: William F Hammond <hammond@csc.albany.edu>
- Date: Tue, 21 Aug 2007 14:59:38 -0400
- To: www-math@w3.org
Richard Kaye <R.W.Kaye@bham.ac.uk> writes in part: > Suppose I write a MathML2.0 document, using these entities. In > a few years time new unicode characters may be introduced, > or the wrinkles in MathML DTDs may be ironed out, and these > entities are changed. Then my document suddenly doesn't display > correctly with the new version of MathML, and the required > changes are highly non-obvious. This wouldn't be a good state > of affairs ... (I'm ignoring what was said later.) IHMO the XHTML+MathML spun out by an authoring interface should not use these names but rather use the corresponding hexadecimal cdata character entities, e.g., "∏". Moreover it is unsatisfactory to have any form of cdata character entity in a format that is transformed to XHTML+MathML because conforming translators will convert them to the actual live characters and that will break some current rendering agents (not always their fault -- so be patient). It's certainly important to have names in authoring interfaces. A limited number of such names can be made available as empty elements (but then they must be fit structurally into the document type definition, which is a burden but not a huge burden). Or we could petition higher powers to allow SDATA entities in XML, version > 1. The difference is that, while they need definition when there is a document type definition, they do not need to be fit into document structure (other than where normal characters are allowed to go). There is even a sane way to understand XML documents with SDATA entities as "standalone". In that regard (undefined) SDATA entities in a standalone XML document would be parallel to empty elements. In both cases a rendering agent needs to recognize the names. In fact, as things are now, we apparently have at least one rendering agent that in math zones ports many of these characters back to the names for internal handling -- nearly a de facto re-introduction of SDATA. Cheers. -- Bill
Received on Tuesday, 21 August 2007 18:59:41 UTC