Subject: Re: Netscape Support for XSL - client vs server rant From: Matt Sergeant <matt@xxxxxxxxxxxx> Date: Sat, 20 May 2000 10:33:40 +0100 (BST) |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Netscape Support for XSL - clie, Niclas Hedhman | Thread | Re: Netscape Support for XSL - clie, Niclas Hedhman |
Re: Netscape Support for XSL - clie, Niclas Hedhman | Date | Re: Server-side. Performance Re: Ne, Paul Tchistopolskii |
Month |