Re: Netscape Support for XSL - client vs server rant

On Sat, 20 May 2000, Niclas Hedhman wrote:

> Matt Sergeant wrote:
> 
> > > I'll go out on a limb here, and (to mix my metaphors) will probably be
> > > shot down in flames, but it could be said that the concentration we see
> > > on server-based solutions is not just making up for the dodgy support
> > > currently available in client browsers, but actually reactionary against
> > > the fact that the MS integrated model is actually a Good Thing [TM] and
> > > some folk are loathe to admit it.
> >
> > It's not reactionary at all - but in fact a stepping stone. Certainly
> > AxKit is. Sadly Cocoon is broken by default in this respect, but that's
> > another matter. With AxKit I explicitly have given developers the chance
> > of writing a "Passthru" plugin, so that they can detect browsers which are
> > XSL aware and send pure XML. For people not so lucky the plugin doesn't
> > activite it's passthru flag and they get XML transformed on the server.
> 
> Excuse me for being an e-diot, but what do you mean by "Cocoon is broken by
> default..."?

Please don't get me wrong here. Cocoon is a great product! In fact I've
described it elsewhere as awsome technology. I did not mean that cocoon is
missing any particular feature, or it's broken because a developer has to
add something; if anything, it's AxKit that is missing features that
Cocoon has (although we're catching up fast :)). However it just gets some
things plain wrong. And the key thing is that as a stepping stone, Cocoon
is advocating some broken things, IMHO. The key thing here is the media
types that cocoon supports. To quote the Cocoon documentation (user
guide - heading "Browser Dependant Styling"):

***
 The media type of each browser is evaluated by Cocoon at request time,
 based on their User-Agent http header information. Cocoon is
 preconfigured to handle these browsers:

        explorer - any Microsoft Internet Explorer, searches for MSIE
            (before searching for Mozilla, since they include it too) 
        opera - the Opera browser (before searching for Mozilla, since
            they include it too) 
        lynx - the text-only Lynx browser 
        java - any Java code using standard URL classes 
        wap - the Nokia WAP Toolkit browser 
        netscape - any Netscape Navigator, searches for Mozilla 
***

(where it says "these browsers" it actually means "these media types").

I realise you can reconfigure this, which is why I said it's broken by
default. The W3C technical recommendation specifically links to the HTML4
spec to define how the <?xml-stylesheet?> processing instruction should be
interpreted (even though it may have nothing to do with HTML). The HTML4
spec *ONLY* defines and allows browsers to support the following media
types:

  screen, tty, tv, projection, handheld, print, braille and aural.

The spec explicitly states:

  "Future versions of HTML may introduce new values and may allow
parameterized values".

But Cocoon adding new values is akin to adding new tags to HTML - that's
something that should be standardised by the W3C so that interoperability
is guaranteed.

So, come the day when client side XSLT is well supported, all your cocoon
XML files containing <?xml-stylesheet ... media="explorer"?> will simply
not work, because a HTML4 supporting browser may remove non-matching media
types, and since the above media types aren't W3C ratified (and I doubt
they ever will be), it's very unlikely that browsers will support them.

Whew. Rant over. I like Cocoon, but it got this wrong.

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list