[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSL in the AJAX world

Subject: Re: XSL in the AJAX world
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Tue, 13 May 2008 14:58:46 -0700
Re:  XSL in the AJAX world
     >  Wouldn't the tools
     > needed to work with the JSON data start to cover the exact same
     > functionality as XSLT, a time-tested industry standard?

We just need to drop the conditional tense here.

The tools to work with JSON are just... XSLT.

More precisely, one can process a "json document" directly in XSLT by
using the FXSL function:




as described  almost one year ago here:


So, the argument seems to be essentially which programming language is
better: Javascript or XSLT.

It is not quite correct to compare apples and oranges, and the
difference between a functional and an imperative language goes much
further than that. Having said this, however, it must be obvious what
is the preference of the members of xsl-list.

Below is just an example. Suppose I need to process the latest data
from Yahoo's Traffic Service (served as JSON) in order to see if there
has been any incident on I-90, so that I could choose another road and
avoid any resulting congestion.

This is essentially a 1-liner:

	         [type eq 'incident'
	         contains(Title, 'I-90')

The result is:

   <Title>Disabled vehicle, on I-90 WB at WESTERN HIGH RISE</Title>

and here is the complete code:

<xsl:stylesheet version="2.0"
 exclude-result-prefixes="f xs"


 <xsl:import href=

              <xsl:template match="/">
	  <xsl:copy-of select=
	        [type eq 'incident'
	         contains(Title, 'I-90')
  <xsl:variable name="vstrJSon" as="xs:string">
         "Title":"Slow traffic, on I-5 SB at S HOLGATE ST",
         "Title":"Disabled vehicle, on I-90 WB at WESTERN HIGH RISE",


Dimitre Novatchev
Truly great madness cannot be achieved without significant intelligence.
To invent, you need a good imagination and a pile of junk
Never fight an inanimate object
You've achieved success in your field when you don't know whether what
you're doing is work or play

On Tue, May 13, 2008 at 12:46 PM, Scott Trenda <Scott.Trenda@xxxxxxxx> wrote:
> Karl,
> It sounds like you are pushing to try to reinvent the wheel in JSON. I
> do agree that JSON is the perfect format for small amounts of static
> data, such as quick status updates via AJAX. However, as soon as the
> content relayed between client and server becomes anything relatively
> complex, JSON runs out of unique constructs to represent that data.
> These tools that you refer to must cobble together half-solutions in
> JSON to represent data structures that XML handles natively (namespaces,
> attributes, repeated elements, etc).
> I don't want to say one is authoritatively Better than the other here.
> However, when your client-server AJAX data reaches a certain point of
> complexity (a CMS should easily fall into this category), your data will
> be around a certain size in either JSON or XML. At this point, why would
> JSON be faster, or even a better choice for the data? Wouldn't the tools
> needed to work with the JSON data start to cover the exact same
> functionality as XSLT, a time-tested industry standard? What is it about
> XML that renders it unsuitable for use in a "fast lightweight and
> possibly frequent" means of data transport in an AJAX solution?
> The link I'm not seeing here is between how you *could* use JSON
> everywhere, and why you *should* use JSON everywhere. Perhaps I'm
> hearing the latter while you were only saying the former. ;)
> ~ Scott
> -----Original Message-----
> From: Karl Stubsjoen [mailto:kstubs@xxxxxxxxx]
> Sent: Tuesday, May 13, 2008 1:50 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  XSL in the AJAX world
> To develop an Ajax solution means that you understand that you are
> after fast ligthweight and possibly frequent requests from client to
> server.  The best data transport mechanism for this is JSON.  Now with
> the support to create templates that transform JSON arrays into HTML
> content on the client's browser using JavaScript libraries like
> Prototype.js or JQuery, you can achieve a declerative solution,
> certainly no where near a true XML/XSL solution, but at least your
> aren't stuck writing out HTML elements in code.
> Having said the above, I ALWAYS develop my initial page load from an
> XML / XSL transformation.  I may even grab the first batch of data in
> XML and transform with XSL.  However, I than rely on simple Ajax
> requests to update and refresh active lists and content on the client.
> Oh, and don't forget, that the JSON string result is easily, and let
> me emphasize (EASILY) achieved with a server side JSON converter, such
> as JSON.Net.  You can throw XML at the converter, complex structs, and
> even compose your own JSON results using the API in your server side
> code.
> Karl..
> On Tue, May 13, 2008 at 8:53 AM, Michael Dykman <mdykman@xxxxxxxxx>
> wrote:
> > On Tue, May 13, 2008 at 11:36 AM, Nick Fitzsimons
> <nick@xxxxxxxxxxxxxx> wrote:hat
> > > On Tue, May 13, 2008 4:19 pm, Andrew Shooner wrote:
> > >  > I develop websites using the XSLT-based Symphony CMS, and another
> user
> > >  > shared a comment he received that XML/XSLT was 'so 1990's'. It
> was
> > >  > suggested to him to move on to JSON-based languages/technology.
> My
> > >  > response was that it has to end up as XML in the end, so there is
> at
> > >  > least some use for it.
> > >  >
> > >  > So my question is, are there many AJAX developers on this list,
> and if
> > >  > so, how frequently, and in what capacity, do you use XSL in
> building or
> > >  > customizing AJAX web applications?
> > >  >
> > >
> > >  I use XSLT to allow the same content to be served as either XML,
> HTML or
> > >  JSON according to the client device's preference. Most JSON APIs
> offer
> > >  similar choices; how many use XSLT to achieve this goal is a
> different
> > >  question, but to my mind it's a perfect application of the
> technology.
> > >
> >
> > Warcraft.
> >
> > I'm building an application similar to Nick's model; XML output from
> > the application is matched with a device profile selecting an XSL1
> > template. Either the a processing instruction is merged in to the XML
> > or it is transformed, depending on the client device's capabilities.
> > In an Ajax envrivoment, JavaScript has access to the same transform
> > engine that the browser does which I use to do apply transforms on the
> > fly.
> >
> > If you want to see a really slick browser example with lots of modern
> > eye-candy, check out Blizzard's home page for Worlds of Warcraft.
> >
> >
> > --
> >  - michael dykman
> >  - mdykman@xxxxxxxxx
> >
> >  - All models are wrong. Some models are useful.

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.