Reservations about <mchar>

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.

---
RBS

Received on Friday, 28 April 2000 22:11:09 UTC