Re: HTML5 @ W3C

> The noises have built into a rumble, to the point of reaching the man  
> himself, Sir Tim BL, if we have to name him:
> http://dig.csail.mit.edu/breadcrumbs/node/166
> "Some things are clearer with hindsight of several years. It is  
> necessary to evolve HTML incrementally. The attempt to get the world  
> to switch to XML, including quotes around attribute values and slashes  
> in empty tags and namespaces all at once didn't work."

This is problem of HTML that has to deal with its own legacy. MathML has its own legacy problems that are completely different however, as we don't have bilions of tagsoup MathML pages to be dealt with.

> Juan & The While Lynx: the quote above is not from hixie or me, culled  
> from the MathML-in-HTLM5 thread. It is a quote from the man himself.  

You don't need to convince me, it is difficult and unnecessary, there are 20+ other members in Math WG (thus one vote does not change much) and if something wrong has to be done it can be successfully done without me. Especially taking into account that WG has a longstanding traditions in this area.

> Needless to say, not everybody agrees with the move, 

Well, saying thank you very much for implementing XML, XSLT, XPath, SVG, XML Events, XHTML, WML, but now we changed our opinion and now please repeat it once again with tagsoup parser, IMHO is not something that adds credibility to W3C if final plan is to go in that way.

> Anyway, all I can add as far as MathML is concerned is that whatever new WGs the W3C ends up with, MathML should become part of the next HTML, period. 

MathML already is in latest version of HTML (i.e. in XHTML 1.1 through XHTML Modularization).

> Let's make a block behind this, and not fragment  
> ourselves any further with wishful thinking and the illusion that  
> MathML is fine in the icy isolation of XHTML/XML.

Isolation of XML? That is something new, being in XML it can be combined with plenty of XML applications, including but by no means limited to XHTML (which by the way has nothing to do with mathematics and is not the best markup to capture structure of scientific articles). I don't know how moving from extensible markup to something that requires spec level and parser level changes each time new element/attribute is added, addresses isolation problem. It apparently does not addresses it, and can not address it as problem is elsewhere not in XML, if presentational MathML is the way to render mathematics in browser then it will remain to be isolated as long as it is not part of (X)(HT)ML/CSS/Unicode environment. 
If someone thinks that removing X from XHTML will suddenly change everything and all problems will go away, then think twice about what one will get, what one will loose, what are actual reasons for low adoption of MathML and how it can be resolved. If one does not like to think, then just look. Look how other markup languages work and how they evolve. Look at LaTeX, it is not the input syntax that makes in meaningful, it is being part of extensible environment with powerful formatting mechanism that makes things work. Look at ISO-12083, it is not the (almost undocumented) DTD that makes the concept valuable, it is idea of markup for (nowadays dead) SGML/DSSSL environment that can be embedded in other SGML applications, this is what is valuable. Look at ECMA OMML, note that even Microsoft realized that mathematical markup should be part of extensible environment. Now look at people that still play with bunch of tags, trying to make sense out of set of presentational elements. Sorry, but it is a completely wrong concept altogether, it never worked for other markup languages, it did not work in case of MathML and it will never work.

Mathematical markup has to be part of extensible framework and it can not be extensible if each extensions requires one to rewrite parser and make changes in rendering engine, it can be extensible only if you have extensible markup and powerful mechanism to configure rendering engine to handle new stuff, this could be pair of meta markup and style language that do the job, this could be something else with equivalent functionality, but if you have nothing like this, then sorry, moving couple of times from XML to tagsoup will not add any value to abstract set of tags.


> Math rendering should not miss out this time. 

Does HTML has something to do with rendering? If not, then I don't understand how round trip from HTML to XHTML and back addresses rendering problems.

> Pretexts are over, as we now have credible things to put on the table.

If at least browser developers would agree on what are credible things and would put them on table it would be nice. But from one can I see, looking at whole story it does not seem to add any credibility to any party involved in process. Just changing notations, while leaving fundamental issues unresolved is not the most credible thing to do.

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

Powered by Outblaze

Received on Monday, 30 October 2006 13:07:09 UTC