Re: MathML-in-HTML5

| Discussion started at
|  http://groups.google.com/group/mozilla.dev.tech.layout
|  http://groups.google.com/group/mozilla.dev.tech.mathml

> XHTML is the web language of the future -- and it always well be. It 
> might as well be dead.

MathML is not necessary confined to XHTML, it may use other XML application as host languages. In particular one can name several XML applications that are much more suitable for encoding scientific articles then XHTML (NIH Journal Publishing DTD, DocBook, TEI). Of course XHTML will remain to be the most widespread host language for MathML, but it is not something that MathML absolutely depends on. And XML in general is apparently not dead, it is enough for MSIE to fix their broken parser and the people that yesterday argued that we all must switch to XHTML, today argue that HTML5 is the only way to go, tomorrow may adjust their opinion once more. It should not be a problem.

> Languages that are not easy to write are ignored

Well compare XML
<mmultiscripts><mi>A</mi><mprescripts/><none/><mi>B</mi></mmultiscripts>
and HTML
<mmultiscripts><mrow>A</mrow><mprescripts></mprescripts><none></none><mrow>B</mrow></mmultiscripts>
that being processed by parser will generate mi-mo-mu tagsoup automatically
<mmultiscripts><mrow><mi>A</mi></mrow><mprescripts></mprescripts><none></none><mrow><mi>B</mi></mrow></mmultiscripts>
So how switching to HTML helped to make language human processable?

I am definetely for turning MathML into human processable language, and removing mi-mo-mu (explicit markup is useful for stuff like integrals, N-ary operators, delimiters, but otherwise it is just bloat <mn>2</mn><mo>+</mo><mn>2</mn><mo>=</mo><mn>4</mn>),  however this can be done and should be done whithin XML, without introducing telephatic parsing rules. If mi-mo-mu are not available in original source and are generated by parser then their semantic value is exactly zero (and yes I know that it is close to zero in any case). ECMA approach is one possible way to remove mi-mo-mu and add use something like <nary> (but not exactly <nary> construction which is the most CSS unfriendly part of ECMA math markup) for operators and just <i> for italic.
So we should either remove it from MathML (the problem however is lack of consensus in WG on issue) or keep it. Removing it from source but keeping in DOM does not make any sense, as you remove semantics but keep this stuff in DOM. 

> Although the MathML community is self-contained today, we all know 
> what happens to species that evolve on islands: they get smaller and 
> prone to extinction.

Integration with environment in which formulae are embedded is crucial for any mathematical markup. All other approaches are closesly integrated in some extensible framework with powerful formatting mechanism (LaTeX/TeX, ISO-12083/SGML+DSSSL, OfficeMath/WordML). Extensibility and availablility of fullfeatured style language or equivalent formatting mechanism are crusial here. In case of MathML environment is web, so integration of MathML into extensible framework is integration into XML+CSS+DOM which is on agenda of Math WG. In contrast HTML5 does not give us extensible framework and ad hoc parsing rules does not help us to integrate MathML with CSS while keepind DOM synchronised with actual markup.


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

Received on Monday, 2 October 2006 09:33:14 UTC