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

I nearly missed this pile of crap. PT has been on my ignore list for a
long time because of his constant tirade against clientside xslt. It
seems that it is only he that has problems with my site thousands of
people don't. I think that his last bug report was that the voting
section doesn't work. This shows that he can view the site with his
browser (ie5 at the time) and that he is continuing his insults against
clientside xslt and my site in particular. GROW UP PT!!!!

Ciao Chris

XML/XSL Portal

> -----Original Message-----
> From: Paul Tchistopolskii [mailto:pault12@pacbell.net]
> Sent: 08 September 2001 21:24
> To: Max Dunn; 'xml-dev'
> Subject: 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 ?  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

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>