Browser support of XML standards (WAS: RE:Slightly off, but... was: XUL appears to...)

["Manos Batsis" <m.batsis@bsnet.gr>]

> From: J. David Eisenberg [mailto:catcode@catcode.com] 

> Rather
> than compile in support for such things as MathML or need Microsoft's
> weird "binary behaviors" to put SVG into an XHTML page,

About behaviors, that's not SVG; that's the predecessor named VML
(vector markup language ;-)

> I propose
> "namespace plug-ins".
> 
> Consider: a browser now gets some MIME type that isn't 
> text/html, so it
> looks up the MIME type in a list of plug-ins and throws the 
> data to the
> appropriate plug-in, which returns some sort of result 
> through the plug-in
> API.

At first glance it's not a bad idea for pushing browsers a little
further but essentially you are actually talking about object tags
(without the object tag...). Native support is much better than this
approach; having different handlers for each subdocument has certain
disadvantages. Here's some:

* The plug-ins have to be specific for each browser (for example activeX
controls in IE). This is the main reason I dislike IE's XML support;
it's not actually in the browser but on a separate dll used as activeX
(msxml).
* You will never be certain on the level of communication between all
those different plug-ins.
* You will have to use DOM extensions for all the above.


> Why not have some API such that, when the browser hits markup with a
> namespace whose URI it's not equipped to handle, it throws 
> the data to a
> plug-in which returns a "box" with the appropriate display 
> (which might be
> a graphic for SVG, text and graphics for MathML, or an audio 
> control panel
> in the case of VoiceML) to the browser. All of this would be 
> done through
> some publicly-advertised API.

If that API is a standard instead of browser specific technology, sure.

Regards,

Manos