Chris Rowley writes:
: > if you accept this, then the XML/MathML world is no different. make up
: > a new language, using XML syntax, to say whatever you want
: > <foo n="3">x<bar>y</bar></foo>
: > (forget the verbose syntax for now), and then provide the XSL
: > transformation script which maps that to presentational MathML.
: I have been reliably informed that XSL does not allow specifications
: that are expressive enough to do this job (basically since it knows
: nothing about maths, in the sense that it has no concept of arithmetic).
I certainly hope that the suggestion is valid even though XSL may not
be adequate to the task.
The use of anything other than XSL for web-served materials is likely
to be difficult.
But in this context the processing from a TeX-like language to
xml is in-house. I see no reason to suffer any restrictions that
might be imposed by XSL. A more general SGML or XML processor
should be able to do anything that is wanted. Even a processing
framework like that of Megginson's sgmlspm/sgmlspl or, for xml
purists, his sax, should be able to do the job.
The real question is:
Just what job is required to write MathML safely?
Since MathML is completely specified and mathematical notation, as
used by most LaTeX (or TeX) authors, is not specified with a matching
degree of precise structure, we need to arrive at a mathematical
understanding of what needs to be done to supplement mathematical
notation, as it has been used through the years.
For example, we need to understand exactly why mathematicians have
no trouble parsing
\sin ax \cos bx .
Absent that, LaTeX authors will never have a way to know if their
documents will be safely translated without in some way providing
parallel MathML code for every math environment.