Re: Reservations about <mchar>
> There is more to this than just CPU. Deprecating entities means
> they are going to be obsoleted/removed in the next versions.
Any application that deals with MathML V1 must always support
a MathML V1 feature, not matter if it is deprecated latter or not.
When MathML V1 becomes unimportant, is probably up to the marketplace.
As with most good software, it makes sense to support reading older versions
as much as possible. This is the rationale behind section 220.127.116.11 of the
MathML spec, which specifies what "deprecated" means:
MathML 2.0 contains a number of MathML 1.x constructs which are now
deprecated. We now clarify the relation between deprecated features and
MathML 2.0 compliance.
1. In order to be MathML-output-compliant, authoring tools may not
generate MathML markup containing deprecated features.
2. In order to be MathML-input-compliant, rendering/reading
tools must support deprecated features if they are to be MathML 1.x
compliant. They do not have to support deprecated features to be
considered MathML 2.0 compliant. However, all tools are encouraged to
support the old forms as much as possible.
3. In order to be MathML-roundtrip-compliant, a processor need only
preserve MathML equivalence on expressions containing no deprecated
As to entities, it was very important for MathML V1 to use them because
so many entities had no public-space Unicode values. Encoding the
private space values into a document would have been bad. The lack
of Unicode values will be remedied (almost certainly) by Unicode V4.
So it is reasonable to consider deprecating named entities and using
only numeric entities.
The <mchar> element was added in November, 1999. At that time, it was
clear that schemas would not support named entities. At that time,
it was *not* clear that almost all of the MathML characters would (almost
certainly) be part of Unicode V4. Now that it is clear, it is reasonable
to reconsider the decision. Not adding <mchar> and recommending the
use of numeric entities is obviously bad for readability. It might be
bad for other reasons too.
(speaking for myself, not the MathML committee)