Re: SVG and MathML in text/html

On Mar 10, 2008, at 22:15, Julian Reschke wrote:

> Henri Sivonen wrote:
>> And, yet, XML is consistently failing on the Web. XML is succeeding  
>> in enterprise system integration. But the moment people try to  
>> produce XHTML or RSS, it is revealed that XML is too hard for the  
>> kind of mass authoring that text/html works for.
>
> FUD. XHTML and RSS are extremely bad examples,

They are the most common XML vocabularies exposed to the masses of  
authors.

> because they suffer from clients that do not use XML parsers.

Why is that?

> Atom, for instance, works much better.

http://hsivonen.iki.fi/atom-xhtml/

>> I recommend anyone who still thinks xmlns is a good idea to look at  
>> the 10th anniversary threads on xml-dev.
>> Even well-knows XML people say that namespaces are
>> * "controversial" http://lists.xml.org/archives/xml-dev/200802/msg00146.html
>> * "done badly" http://lists.xml.org/archives/xml-dev/200802/msg00149.html
>> * presumably needing "fixing" http://lists.xml.org/archives/xml-dev/200802/msg00221.html
>> Also check out the comment from David Megginson over at Tim Bray's  
>> blog:
>> http://www.tbray.org/ongoing/When/200x/2007/09/14/Lousy-Aggregators
>> Considering that even XML folks admit Namespaces in XML is bad, it  
>> would be silly for us not to try to shield hapless HTML authors  
>> from the badness to the extent possible.
>
> It would be interesting to see what a better solution would have  
> been. I think the problems with namespaces are well understood, but  
> that doesn't mean it is simple to do things better.

Putting all the element names from the Web platform languages (XHTML,  
SVG, MathML) into a single space of XML element names without any URI  
binding mechanism. That is, if HTML defined "table", it is taken and  
MathML should define "mtable".

>>> Maybe it’s because I’m used to writing SVG, but I really don’t  
>>> have a problem with the concept of mixed namespace content.
>> I have a problem with namespace URIs every single time I need to  
>> deal with XHTML, SVG, etc. I always have to waste time looking up  
>> and URI to copy and paste because trying to go by memory and  
>> getting it wrong (which year? trailing slash?) would waste even  
>> more time.
>
> I fail to see how this is a problem. Is copy & paste too hard?

Yes, when the plausible alternative is not having to do that.

>>> In fact, all browsers except for IE can handle application/xhtml 
>>> +xml MIME type these days, so it really seems to me that the  
>>> verdict’s still out on whether XHTML is a good technology or not.
>> Even if XHTML is good technology as far as pure technology value  
>> goes with network effect considerations, XHTML flunks Technology  
>> Strategy 101 by failing to plug into the existing the network of  
>> the text/html installed base.
>
> Not sure what this means.

Oops. the first "with" was supposed to be "without".

Pure technology value is a characteristic of a given technology  
without regard to how it interacts with other stuff. For example, the  
number of polygons a game console can shade per second is a  
characteristic of the game console that doesn't depend of external  
factors. A game console becomes more valuable when there are more  
games available for it and more games become available as there are  
more console units sold. A game console with higher shader throughput  
but no games is of no value compared to a less performant console that  
has a lot of games available for it. When a new console with almost no  
games is launched, it is less valuable than a console from the  
previous generation with a lot of games. A smart strategist creates  
the new console to leverage the network effects of the existing  
ecosystem by making the new console compatible with the games of the  
previous generation.

XHTML totally failed to use the well-known strategy of leveraging the  
existing network effects by being compatible with the installed base  
of the previous technology generation.

http://en.wikipedia.org/wiki/Network_effect

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 10 March 2008 20:51:29 UTC