Re: Errors in the test suite

> I thought to exit CR you had to show interoperability. Requiring per-UA
> hacks to get them to render MathML doesn't really count IMHO...

interoperability of MathML. The fact that you need different things to
load MathML into different UA is unavoidable. 

MathML[Import]("<math>....

works in Maple, but isn't going to work in Mozilla. That's life.

Of course if you restrict just to xhtml browsers the situation could be
better but...

It would be nice if you could freely mix arbitrary namespaces to
arbitrary depth and the UA just "did the right thing" but that just
doesn't happen at the present time and as you'll know there have been
several coordination efforts to try to make things better, that isn't
specifically a MathML problem.

I'd say that the situation in the MathML test suite is better than the
current situation with SVG for example where as far as I can see the SVG
usually (or at least often) has to be in an external file and pulled in
via <embed or <object or something. The files are (baring bugs) valid,
conforming xhtml+mathml documents, the PI is just a small concession to
present realities.

The .mml/.png files  form a full test suite of_MathML_ capability.
The xhtml files together with javascript folding tables of contents etc
allow _humans_ to browse over the test suite in a confortable way.
Posting the files in a form that no current browser could use would not
help the human reader greatly.

As it happens MathPlayer 2 has since come out and so one could set the
files up without the PI (and possibly with a doctype) and MathPlayer
would render them. Mozilla would then fail all the content MathML tests,
which you might say is a correct result, but it paints a blacker picture
than is needed: It is easy to set up your file so that mozilla and IE
can render xhtml+content mathml, and the current test suite allows the
testing of that configuration. If you add a doctype though IE 6 prior to
sp1 would fail all tests (fail to load any of the xhtml as a bug
unrelated to mathml means that it won't read the dtd (it won't read any
character reference to a character outside the basic plane of unicode)
Thus if you strictly followed the xhtml modularisation conformace rules
you would have to have a doctype and would then be unable to test
mathplayer at all (in the IE current at the time the test suite was
made). 

If the test suite was to show/test mathml rendering as opposed to
testing bugs in browsers XML parsing, embedded language support or other
such external factors, the xhtml wrapper files have to walk a tightrope
between non-conformance to the standards and failure to work in
implementations. For Content MathML in particular I believe that the
stylesheet PI is still the best approach. I would rather say that
mozilla's mathml support is split between its xslt engine and its native
renderer than say that it does not support content mathml.
If you want to publish documents including content mathml such details
are irrelevant.



David




________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Received on Thursday, 22 April 2004 10:16:09 UTC