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

[Paul Tchistopolskii <pault12@pacbell.net>]

> 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 ?  Well, I've tried both 'version 6' browsers 
on my poor computers at work and ... Those lost souls
who upgraded version 5 to version 6 look helpless to me. I mean, 
in could be that version 6 of both browsers has some CSS or XSLT, 
but both IE 6 and Netscape 6 are just ... crushing all the time ...
But that's 'aside'.
 
> I don't understand what you are saying about "a small percentage of
> immaculately configured machines"?  Isn't 99% of what people use for
> browsers today far less "fat" than what is required for client-side
> XSLT?

??? Yes!!!  To use XSLT client-side one has to install either 
Netscape version 6 or IE version 6. Both are too fat, comparing 
to NS version 4 and IE v 5.

I don't know about 99%, but from the logfiles of my website, 
the percent of v 6 browsers is not more than 10%.
 
> I have noticed a ton of CSS on the Internet.  Quite common amongst
> blogs, for example.  Some even go so far as to detect what form of
> browser you're using and send appropriate content.

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 ???

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* ???

I'm wondering when those constant speculations about client-side 
XSLT will stop and we'd just discuss the *particular* client-side 
XSLT solutions that people implement ( *if*any*). 

The Chris Bayes' URL provided by you is accessible by a 
fraction of people. It is interesting for those 10% who've installed 
version 6. Are you talking about the intranet? 
If yes - why you're jumping to 'blogs'-are-detecting-the-type ?
Are you talking about the *Internet* ??? 

If you do talk about the *Internet* - nobody builds the Internet 
apps on client-side XSLT. Period. Nothing to discuss. 

> Of course only time (and the actions of large companies such as AOL and
> Microsoft) will tell, but I think there is fantastic potential for
> client-side XSLT and it will be like other "modern" technologies such as
> JavaScript (or do you use that yet?): detect whether they have it, and
> if so, take advantage of it, within the limits of their implementation.

This 'time-will-tell' mantra abour client-side XSLT is at least 3 years old.

I think it will take at least 3 more years to get more than one person
supporting it IRL. Chris Byes is the only guy who constantly plays
with this client-side XSLT. Because of that,  his website 
was *always* crushing my browser, every time I visited his 
pages for last *years*.  And I've  stopped providing him with 
particular bugreports after I realized that he does not care
about such a small things like browser crashes.  He has a universal 
excuse : "it is bleeding edge, it is OK to crash". 

Something has really changed with the software development.

I don't expect the number of those 'clisnt-side XSLT' 
people to be more than, say, 100. 

'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 ).
 
> The closer to compliance with a spec most implementations are the better
> for everybody, but being ready for multiple bad implementations is
> certainly nothing new in coding for the web.  XSLT will flourish on the
> client, now that there are at least two attempts at it out there.

Mantras are good. I think XML Everywhere is right on this tiopic.
When somebody wants you to apply a mantra or  other religious 
construction for solving an engeneering task, the only 
reasonable answer could be :

> Client-side XSL?
> What are you smoking?

<some other quote>
The bottom line is: the server can determine is the user agent support XSLT
or not. If yes, the process can occur at the edge or at the client site.
Otherwise at the server side. As more client support XSLT transformation,
less server load you'll have. Is using a 1 ghz client to perform dummy
rendering a best way to use resources? What about distributed computing 101?
</some other quote>

This client-side XSLT business is a couple of years old.
Show me the money, pelase? I mean where is this scenario implemented 
and what was the *reason* of implementing it *this* way ( because I don't
see *any* practical reason ).

If it *was implemented*. Maybe that 'dictributed XSLT' picture looks 
nice on paper, but where is it IRL ?

Rgds.Paul.

http://www.spafi.com  - Smart Spam Filter for Windows