- From: Roger B. Sidje <rbs@maths.uq.edu.au>
- Date: Wed, 03 May 2000 11:23:36 +1000
- To: David Carlisle <davidc@nag.co.uk>
- CC: rminer@geomtech.com, www-math@w3.org
David Carlisle wrote: > > If however the implementation costs on mchar turn out to be too high > I agree that we might need to reconsider this....... Yes, it is going to be expensive (and verbose too :-). For example, if implemented in Mozilla now, the MathML code will also be keeping its own data structures to resolve the names, thereby duplicating what the XML parser is already doing. Plus, there will be the overhead in the creation and rendering of associated "frames". Since <mchar> is an alternative to entities that are widely-accepted and supported very well with a simpler <!DOCTYPE SYSTEM "mathml.dtd", it didn't seem okay to me that it should have such overhead. I should perhaps also note that with Mozilla, the list of entities "mathml.dtd" is auto-installed (when the browser is installed) in the bin/dtd directory (pretty-much like the bin/pluggins directory). And since this resides in the client-side, the overhead to load it in <!DOCTYPE SYSTEM "mathml.dtd" is not too much. Therefore authors can copy-paste hand-written fragments that use the MathML's REC standard entity names without much worry. I understand other renderers have built-in knowledge of these entities (or at least, some part that could be extended when the REC settles down). That's why I was inclined toward not deprecating the entities, and waiting a little bit before considering introducing <mchar>. --- RBS
Received on Tuesday, 2 May 2000 21:24:08 UTC