Reservations about <mchar>
Subject: Reservations about <mchar>
From: "Roger B. Sidje" <email@example.com>
Date: Sat, 29 Apr 2000 12:00:56 +1000
From firstname.lastname@example.org Fri Apr 28 22: 11:09 2000
I have a number reservations about <mchar>, and I feel its introduction
is premature. I understand the motivations in introducing it, but from
an implementor perspective, I see that at this stage, the disadvantages
of <mchar> outweigh its benefits. I think it is best to wait for a
general solution from the XML language itself. Perhaps XML should support
a different class of inline-replaced "&&Entity;" that are not reported as
an error if they are unresolved, I don't know. That's a question for the
XML experts. But using <mchar> as a work-around raises other serious
problems. That's why I thought I should bring these reservations to the
consideration of the W3C MathML Panel.
Here are some of the problems with <mchar>:
* foster incompatibilities
since the same char be known under different names depending on
the usage and field of interest, it is hard to set a definitive list.
(cf. the listing at http://www.mozilla.org/projects/mathml/fonts/chars/table.html
which is best viewed with a Mozilla MathML-enabled browser).
The trick of quickly aliasing in the &Entity; list provides a satisfactory
solution to this problem in a standard-compliant manner.
With <mchar>, there wouldn't be a standard-compliant way for the
users to resort to that trick and use the most relevant names
w.r.t. to their context.
* poor extensibility
- have to wait for next releases of renderers to see built-in support
for a new name.
- or have to suffer incompatibilities if each renderer provides
its own way to extend its client-side list.
* consume memory and slow to process
- since it is a <tag>, it is part of the persistent XML/DOM tree, therefore
a document with a lot of <mchar>, as it will typically be the case with
scientific documents, will consume more memory, and will furthermore be
considerably slower to render - gone is the speedy substitution that was
done at parsing time by the (generic) XML parser on the &Entity;.
- some implementors may think that, since it is a <tag>, it would have
to be exposed to DOM events, meaning even more trouble given that
hooks/resources will be allocated in anticipation of users' actions
on the tag.