OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Client-side XSLT. Re: Bad News on IE6 XML Support

>> So he should shut down http://www.bayes.co.uk/xml/ ?

> This URL actually points to something??? Sorry, my IE v 5 
> and Netscape v 4.7 don't work on that page. I suspect that 
> I should use Netscape 6  or IE 6 ?  

IE 5 or greater with MSXML in "replace mode" will work.  Yes, that
particular site is aimed at a browser that supports client side XSLT and
was developed when IE 5/MSXML 3 were the only real option for client
side XSLT.  I don't think it will work with Netscape 6 yet.  Here's a
more polite site for you to get less upset about:


Note that it has a little link on the side for the adventurous.  That's
more what I was suggesting as a way to use XSLT on the client (i.e. one
option with alternatives for other browsers).  And look, it was less
than 3 years!

> To use XSLT client-side one has to install either Netscape 
> version 6 or IE version 6. 

No.  IE 5 and MSXML 3 will actually let you view that site just fine.
It isn't *convenient* to go track down MSXML and xmlinst.exe (and it's
unlikely any non-programmer users would ever do that, though they will
download IE 6), but it's quite possible, proof that even such a "slim"
browser as IE 5 *could have* supported XSLT.

> Both are too fat, comparing to NS 
> version 4 and IE v 5.

It is not as if bloated programs are a prerequisite to XSLT (if these
programs are fat, very little of that fat is due to their - limited -
support of XML): you will find, however, that newer programs tend to be
more bloated than old ones.  You'll also notice that people tend to move
towards the new ones anyway.

> That "support for multiple browsers" happens all the time, not 
> only with CSS. I don't understand - you *really* think that in 
> the situation when the task is  to support both HTML-only renderer 
> and XSLT-capable renderer at the same time, some architect may 
> provide a client-side XSLT  based solution  *and* HTML-only 
> solution, *not* providing *just* HTML-only solution based on 
> server-side XSLT ???

It certainly would be nice to use a client that has the computing power
prerequisite to *any version* of IE/Netscape (none are particularly lean
by application standards) as something other than a dummy terminal.

I would hope that over time non-XSLT-supporting clients are treated the
way Text-only/Frameless browsers are treated Today.  Give them a version
of the site they can handle.

> I understand that some people may buy the idea of client-side 
> XSLT in the situation when *no* 'pure HTML browser' has to be 
> supported,  but if somebody needs *both* ???

Once you're using XSLT on the server, it does not involve double the
effort to use it on the client, and this can decrease server load and
provided enhanced client-side experience. 

> 'Client-Side XSLT' ??? What are we talking about? 
> There are millions, who *use* JavaScript. And see how 
> fast JavaScript was adopted. Compare it to the growth of 
> this 'client-side XSLT' stuff  ( which *was* availiable in the 
> browser for *years*, even in the crazy MSIE form of it ).
There I completely disagree.  The "crazy MSIE form" was *not* XSLT.
That never should have been released as anything other than a technology
preview, and should absolutely not be cited as some sort of evidence
that XSLT has been around for years.