- From: Roger B. Sidje <rbs@maths.uq.edu.au>
- Date: Tue, 03 Oct 2006 15:48:17 +1000
- To: White Lynx <whitelynx@operamail.com>
- CC: dev-tech-mathml@lists.mozilla.org, www-math@w3.org

On 28/09/2006 10:44 PM, White Lynx wrote: > I consider switching from XML to text/html as inappropriate and > pointless development, morover it is damaging in long term perspective. Damaging to what? To MathML? Not really in my opinion. What damage could there be to have plenty of MathML formulas on the web?!? But to the XML/XHTML agenda, possibly. And that has been the real "problem" since the beginning, and which I alluded to in my opening post. It wasn't a fight fitted for a niche MathML that was already struggling to make a name for itself. Interested in using MathML? First pass that XHTML barrier, and that wasn't even a small barrier. It was a significant barrier, taking seven years before IE understood application/xhtml+xml. As for the fact that "the people that yesterday argued that we all must switch to XHTML, today argue that HTML5 is the only way to go". Speaking generally (or specifically w.r.t. MathML)? People had to switch to XHTML to get MathML -- it wasn't even a matter of choice. C.f. again this very insightful post on the matter. http://groups.google.com/group/netscape.public.mozilla.mathml/msg/4d58c35217afcb54?dmode=source So after all these years making the case for something else (XHTML), what this thread is about is to make <math>...</math> works everywhere, especially where it still matters the most today, and that is HTML5. As I indicated, my original take is for <math>...</math> to work as-is -- as we have come to know and enjoy it. But it is obvious that this new mixing has to be defined somehow, even if we later come to a conclusion saying that it is an opaque <object>, or a profile of some sort. But I hope that as further insight is gathered through the proof-of-concept, it turns out that <math>...</math> is just fine, and that interoperability issues won't be thrown at an already special niche technology. While on this, I should stress that tag-soug is possible anywhere, although this is often not mentioned because the extent is much different. Well-formed tag-soup (as odd as it sounds...) is possible, which is why these reddish "invalid-markup" messages sometimes pop in Gecko's MathML rendering. Such things are left undefined by the spec. However, in the case of MathML where the markup is generated automatically by software, there is no particular reason to believe that these generators will suddenly start to generate an indigestible tag-soup. So it is not quite realistic to over-emphasize this issue. MathML already works in XML/XHTML and this proposal is not going to break that. But there is little else to gain there (as far as MathML in concerned). Publishers who use XML in their back-end production line can continue to do what they have been doing. However, MathML stands to win more (especially individual users) in the front-end by being in HTML (HTML5 for that matter). This might also encourage those building HTML authoring tools to consider interfacing MathML (either with free or commercial plug-ins) because the XML/XHTML barrier won't be standing right at their face. (On the issue of the verbosity of MathML, this wouldn't be much of an issue if people didn't have to stare at the MathML. In fact, when I look at HTML+Javascript+CSS pages these days, they are also quite cryptic... It is possible to have invisible/collapsible MathML in an editor interfaced to a plug-in? Surely for people who have experience building comprehensive editors. But with the XHTML barrier they can't even chime in...) I am sure by now that it should be evident that it is XML/XHTML that stand to lose with MathML enabled in HTML5. Anyway, XHTML doesn't seem to be going anywhere. (How often does one stumble on a page served as application/xhtml+xml -- if it isn't a page with MathML?) In any case, as I indicated, it will still work there, maybe not just as _the_ selling argument that it is now. (Many math pages wouldn't have bothered with XHTML if it had been possible to have MathML in HTML, and that's where their loss might come from. But does it really matter? Read Robert Miner's earlier post again.) To advance MathML, we contributed a great deal to XML/XHTML and pushed for them so much that it is very easy to forget the initial focus. MathML-in-HTML5? Worth a try. The thread is now about the issues in prototyping this, and the benefits (or otherwise) for MathML and math on the web. And I must say I don't see that much disadvantages in enabling MathML everywhere at this point. --- RBS > > > First of all it is unclear where this idea comes from, as MathML > community has no legacy text/html content that one should care about. > All MathML content is wellformed (by definition), which means that one > has less errors in MathML documents comparing to what one would have in > tagsoup approach, it also means that all MathML content can can be > handled with XML tools, can be processed with XSLT, matched using > XPath, mixed with other XML based markup languages (OpenMath, SVG) etc. > There is no single MathML implementation that supports text/html > tagsoup, but does not support X(HT)ML, while inverse is not true, there > are XML only MathML implementations that by definition have nothing to > do with HTML legacy. > > Further it is not clear for me why this has to be done today, after > paying price for wellformedness and tackling XML related problems for > seven years, when finally MSIE/MathPlayer accept application/xhtml+xml > and thus allow people to deliver the same XHTML+MathML to > MSIE/MathPlayer and Mozilla (one can add Opera with UserJS) someone > decides to revert (more precisely convert) everything to tagsoup. > > Profiling policy is sounds unclear and strange to me. Solving issue on > the level "I'm happy to drop/add any tag to this list. Just give me the > list you want" or based on MathML support level on some particular > implementation seems to be irresponsible. > There are at least two subgroups in W3C Math WG that one could drop a > message with profile proposal to after looking at "wrong table". > One is called liason with WhatWG subgroup and as name suggests is > expected to ensure that needs of MathML are addressed in WhatWG specs. > Another is liason with CSS subgroup, which is expected to define MathML > profile suitable for usage in XML+CSS framework and a few CSS > extensions needed to format proposed MathML profile. > There is also subgroup that deals with compound document formats. My > opinion is that profiling of MathML should be coordinated with these > units as irresponsible steps may spoil W3C efforts in the same area. > > One more thing that sounds unlogical and rather strange is that > Mozilla/WhatWG try to move MathML further from XML+CSS framework, > by converting XML to tagsoup with ad hoc parsing rules and embracing > constructions like mstyle, mpadded in "proposed" profile. > > _______________________________________________ > dev-tech-mathml mailing list > dev-tech-mathml@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-mathml >

Received on Tuesday, 3 October 2006 20:54:29 UTC