Re: [whatwg] The problems with namespaces in text/html

>> Yes, exactly the reason they have the correct (MathML) namespace in the  
>> DOM. So they can be rendered, etc. The serialization format doesn't really  
>> matter.

> Like hell it doesn't matter! A DOM doesn't travel over the network. The 
> serialized form does. The DOM is one possible local model used to 
> process the document on one system. My tools may or may not be based on 
> the DOM, but they're going to start by receiving an actual XML instance. 

> I don't care what appears in the DOM. My model is not the DOM. Most 
> models are not the DOM.

Completely agree. This was explained many times, but some people simply don't care what they do and what others think about issue. With the same success one can use LaTeX-like syntax and define DOM as DOM that cooresponds to MathML equivalent of original expression, on practice it means introducing new markup and breaking all existing MathML tools.

>> It sounds to me like the working group is considering the needs of  
>> thick-client web browsers
> The WHAT WG is very much biased towards Gecko, Presto, WebKit and  
> Trident as the consumers of documents.

> But as I keep saying, *it's not just browsers*. There's a lot more 
> happening on the Web than classic desktop browsers. A document posted to 
> the Web is available to all sorts of clients.

I would like to clarify that converting MathML to tagsoup first of all damages web browsers. It is not browser vendors (at least there should be no Presto, no Trident and possibly no WebKit in the list above) who initiated current speculation, it is bunch on individuals who don't understand consequences of their steps, push (mis)concept of Tag-Soup-MathML.

>> Who, exactly is this HTML serialization supposed to help?
> Anyone for whom interoperability in processing real world content is 
> important.  This includes, among others:

> * Browser vendors that have to deal with real world content.

Yep, browser vendors dream about converting well-formed markup to junk, our developers strive to devote their lives to tag soup parsing and error handling. Doubling volume of text/html tagsoup will be sufficient to make this dream come true.

> * CMS, editor, and other tool vendors that have to accept HTML input from users.

There is not text/html MathML content at the moment, no one ever tried to base scientific publishing on HTML as such, what HTML input are we talking about is completely unclear for me. There is no single MathML aware tool that supports HTML and not XHTML. And we have a lot of primary XML or even only XML aware MathML implementations.

> * Authors that have to develop for the real world.

Note that in real world only XHTML+MathML works interoperably in MSIE/MathPlayer, Mozilla and Opera/UserJS. Moving to tagsoup (especially without namespaces) will bring the end to this (only recently achieved) signs of interoperability (not to mention that it will break a lot of non-browser implementation that never had to handle tag soup before)

> * Users who like to surf the web in any browser they choose.

Current proposal breaks interoperablity in short term perspective and splits MathML community into pieces. Microsoft already lanched their own mathematical markup language, Mozilla basically introduces new markup (or new serialization of old markup, which is the same in terms of interoperablility with existing tools). At Opera we counted on MathML as interoperable solution for mathematics, if it will be splitted in propriatary pieces that call themselves MathML (ECMA OMML is often refered as modified version of MathML, while it is completely different language, and Tag-Soup MathML also uses MathML name and also is incompatible with MathML) then its value as interoperable solution will be zero, as it will not bring us interoperability, it will make already contraversial markup worse (up to now it was at least well-formed). We can allocate limited resources for mathematics and provide functionality necessary to display math formulae in Opera, but we really don't have time to run after "big two" and waste time on double "standards" and inter-MathML bickering. Either MathML community should follow one-markup policy and focus on real problems that undermine MathML or one day everything will just cramble away (in this case MathML will not be the first markup language that crashed beacuse of inability of different parties involved in process to consolidate efforts) and as usually no one will learn any lessons from this (at least not those who are supposed to learn something and come up with solution).


> I'm sorry. The use cases so far just don't hold water. I reput the question: who does HTML serialization help? What problems does this solve?

It solves no real problems. It is the way to blame failure to come up with decent solution for mathematical content in web framework on alleged failure of XHTML. And it adds extra problems (no introperability, no extesnibility, no way to combine MathML with other XML vocabularies as one person at WhatWG dislikes namespaces, ambiguous DOM, no opportunity to reuse XML tools, no opportunity to reuse existing MathML implementations, no single organization that is responsible for markup and as a result no single markup, no consensus among browser vendors, now new implementations as no one wants to rely on unpredicatable markup). 

>> Browser vendors can handle XHTML now. It's a non-issue for them.
> Working for one I can assure you it's very much an issue.

Once again, thank you very much for support. I look forward to assign all Tag-Soup-MathML parsing, error handling bugs and browser compatibility issues to you. The only think that I fear is that no one who cries for new serialization here will take responsibility for consequences and as usually someone else (= majorioty of users and developers) will have to pay price for decisions made by those who don't care much whether tomorrow we will have mathematical markup at all (after all they don't use it and can happily live without it).

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

Powered by Outblaze

Received on Monday, 6 November 2006 22:42:35 UTC