Re: [xsl] XSL in the AJAX world

["Dimitre Novatchev" <dnovatchev@xxxxxxxxx>]

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

  f:json-document()

or

 f:json-file-document()

as described  almost one year ago here:

  http://dnovatchev.spaces.live.com/Blog/cns!44B0A32C2CCF7488!367.entry


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:

f:json-document($vstrJSon)/*/*
	         [type eq 'incident'
	        and
	         contains(Title, 'I-90')
	        ]



The result is:

<Result>
   <type>incident</type>
   <Title>Disabled vehicle, on I-90 WB at WESTERN HIGH RISE</Title>
   <Description>DISABLED VEHICLE; RIGHT LANE CLOSED; STAY LEFT.</Description>
   <Latitude>47.589820</Latitude>
   <Longitude>-122.286320</Longitude>
   <Direction>WB</Direction>
   <Severity>2</Severity>
   <ReportDate>1210712434</ReportDate>
   <UpdateDate>1210713430</UpdateDate>
   <EndDate>1210715230</EndDate>
</Result>



and here is the complete code:

<xsl:stylesheet version="2.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
 xmlns:xs="http://www.w3.org/2001/XMLSchema";
 xmlns:f="http://fxsl.sf.net/";
 exclude-result-prefixes="f xs"

 >

 <xsl:import href=
   "file:///C:/CVS-DDN/fxsl-xslt2/f/func-json-document.xsl"/>

              <xsl:template match="/">
	  <xsl:copy-of select=
	  "f:json-document($vstrJSon)/*/*
	        [type eq 'incident'
	        and
	         contains(Title, 'I-90')
	        ]"
	  />
	</xsl:template>
	
  <xsl:variable name="vstrJSon" as="xs:string">
  {"ResultSet":
    {"LastUpdateDate":"1210714091",
     "Result":
       [{"type":"incident",
         "Title":"Slow traffic, on I-5 SB at S HOLGATE ST",
         "Description":"MODERATE CONGESTION; SLOW TRAFFIC; ALLOW EXTRA TIME.",
         "Latitude":"47.586100",
         "Longitude":"-122.320390",
         "Direction":"SB",
         "Severity":2,
         "ReportDate":1210712877,
         "UpdateDate":1210713430,
         "EndDate":1210715231
         },
        {"type":"incident",
         "Title":"Disabled vehicle, on I-90 WB at WESTERN HIGH RISE",
         "Description":"DISABLED VEHICLE; RIGHT LANE CLOSED; STAY LEFT.",
         "Latitude":"47.589820",
         "Longitude":"-122.286320",
         "Direction":"WB",
         "Severity":2,
         "ReportDate":1210712434,
         "UpdateDate":1210713430,
         "EndDate":1210715230
         }
       ]
    }
  }
  </xsl:variable>

</xsl:stylesheet>



-- 
Cheers,
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] 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.