Subject: Re: [xsl] Is letting the browser transform XML to XHTML using XSLT a good choice? From: "M. David Peterson" <xmlhacker@xxxxxxxxx> Date: Sat, 4 Mar 2006 05:25:01 -0700 |
One other significant point: Google decided that the need for a scriptable client side XSLT processor was great enough that it became one of their very first contributions to their OSS efforts. Its written in Javascript, yes, but this, in fact, brings even more credibilty toall of this as they made the decision that this was important enough to get into the developers hands as quickly as possible, that even a non-compiled language like Javascript was better than nothing at all. There are currently 11 OSS projects directly developed by Google. (this doensnt include any of the Summer of Code projects they sponsored). They can be found here > http://code.google.com/projects.html Of these 11 projects, this is the only browser-based project that is not a Google specific API. - MS - Mozilla (see *) - Safari/Konqeror - Opera - Google * Anybody remember these famous last words: --- The Challenge Anything XSL can do in the Web environment, I can do better using technologies supported by current W3C Recommendations. Of course, what is "meaningful" in the Web environment is open to a variety of interpretations. Therefore, the subject of the challenge should be one that the XSL camp and I agree is meaningful. I am also ready to make this bet a little bit more than an academic exercise. If I lose, I will pledge that I, and my crack mozilla development team, will assist in implementing XSL in the mozilla open source project. --- > http://www.xml.com/pub/a/1999/05/xsl/xslconsidered_1.html < --- Who won that bet, anway? Yeah, we did. TransforMiiX enter the world a couple of years later. And now there has been signicant talk of extending support for EXSLT 1.0 once it reaches final rec from the EXSLT group. Browser and Client-side XML/XSLT has gone well beyond theory, and is now very much a reality, and getting better each and every day. If you care about development time/time to market, cost of infrastructure, client-side application performance, and a cleaner, simpler overall design, the solution is quite clear: Client-side/Browser-based XSLT that communicates with a Server side preferably XSLT 2.0, XSLT processor for managing transaction requests from the client. My choice (but I am no where near alone on this) Saxon 8.7 and beyond -- yes, there are other 2.0 engines not developed by Dr. Kay, and not carrying the Saxon label ... And none of them come close to Saxon.. I promise.) -- <M:D/> M. David Peterson http://www.xsltblog.com/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Is letting the browser tr, M. David Peterson | Thread | Re: [xsl] Is letting the browser tr, M. David Peterson |
Re: [xsl] Is letting the browser tr, M. David Peterson | Date | Re: [xsl] Is letting the browser tr, M. David Peterson |
Month |