To clarify, you already mentioned the problem - Moodle is still not XHTML compliant because users can create content which is not XHTML compliant.
At least that's my understanding. This is why we probably can't just turn on the option to serve as XHTML (which is currently on when in debugging mode, at least in our system). In addition, serving as XHTML totally breaks IE6 so is not a solution for those users.
As for my opinions on the proposal, I think the proposal is in general a good idea but I disagree with all the parts Tim L changed after the version I came up with.
[Kidding, somewhat. I'm being unfair - we actually came up with it in a discussion together, wasn't just me at all.]
To review the general idea/bit I agree with:
- Equations by default display as images, with some meaningful alt tag
- If you click on the image you get to a page about the equation, which includes a version presented as MathML, the MathML source, and other metadata such as a TeX equivalent.
- From this page you can, if you wish, turn on a checkbox to enable 'enhanced mode', in which MathML is sent directly as part of normal Moodle pages.
But, here's the bit copied from the blog entry which is what you would put into an HTML area when adding an equation:
< math type="display/inline" >
< mathContent type="MathML" >
... Presentational MathML content
... Optional Content MathML or OpenMath content
< /mathContent >
< mathContent type="image" >
... an image of the rendered mathematics for use when MathML cannot be displayed
< /mathContent >
< mathContent type="html" >
... optional simple HTML/unicode representation
< /mathContent >
< mathContent type="tex" >
... optional tex encodeing
< /mathContent >
... possible other content types
< /math >
As you can see this is humungously long and overcomplicated - and that's in addition to the humungously long and overcomplicated MathML rendition! Also, you cannot include images inside
XML like that (unless you are going to use base64 - PLEASE GOD NO).
I would prefer to include only the MathML content. This is much simpler and is standards-based rather than introducing a random new wrapper standard. Hopefully we can then provide automated rendering for:
- The image (automatic generation via external MathTran server)
- Text equivalent (image alt tag), possibly also via external server
[If we can't provide an automatic text equivalent then we should allow for a custom-namespaced alt attribute on the mathml.]
- TeX (automatic conversion via external MathTran server)
- Simple HTML in cases where it is appropriate - single letters, x2, etc (simple automatic conversion, doesn't need to cover everything, only hit the most-common cases).
No information that can be automatically generated should be stored. (If we need to store autogenerated information for performance, this can be managed through caching.)
We also need to bear in mind that the first iteration of this effort is likely not to include a visual editor because of the complexity involved.
My opinions might change a bit if it turns out we actually can't automatically generate some of the things I thought we could.
(Note that MathTran doesn't support MathML yet, but it's supposed to eventually.)
--sam
