- From: Robert Miner <rminer@geomtech.com>
- Date: Tue, 2 May 2000 09:37:43 -0500
- To: davidc@nag.co.uk, rbs@maths.uq.edu.au
- Cc: www-math@w3.org
Hi,
> * consume memory and slow to process
>
> I didn't understand this argument. It is clear that having mchar means
> that the name has to be resolved by the application rather than the xml
> parser, so more information has to pass to the application. But in what
> way would mchar be different from your &&foo; unresolved entity
> proposal? You would still, in that case have to have some kind of
> special node containing "foo" so that wouldn't be so different from the
> element/attribute nodes would it?
Setting aside the &&foo; idea, and focusing on the <mchar> vs entity
split, then I think I understand the issue. If a MathML processor is
getting a parse tree from the DOM, then the extra <mchar> nodes are
more expensive than entities which resolve to character data. I think
this is the situation in mozilla, isn't it? The mathml processing
takes place after the generic XML parser processes the markup.
This also comes up with some of the plug-in work I have done in IE.
I don't have a clear quantitative sense of the performance hit,
though. A statistical profile of the density of characters needing to
be accessed through <mchar> in a typical document would be very
useful.
--Robert
----------------------------------------------------------------
Robert Miner http://www.webeq.com
Geometry Technologies, Inc. email: rminer@geomtech.com
phone: 651-223-2884
----------------------------------------------------------------
Received on Tuesday, 2 May 2000 10:41:25 UTC