While both formats certainly have thier uses, the fundamental
difference, as I see it, is this: JSON data is typically bound with an
existing document to derive formatting while formatting for XML can be
elegantly and consistently formatted via XSL.
As we all seem to agree, JSON is appropriate for tight data fetches
when formatting is not an issue. But if you are not merging the data
into an existing document fragment, you have to render that document
structure in JavaScript on the fly which is a nightmare for
maintenance (and is somewhat reminiscent of the way we used to produce
documents via CGI back in '93).
Happily, the XMLHTTPRequest object which underlays all AJAX supports
both quite elegantly.
- michael dykman
On Tue, May 13, 2008 at 3:46 PM, Scott Trenda
<Scott(_dot_)Trenda(_at_)oati(_dot_)net> 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(_at_)gmail(_dot_)com]
Sent: Tuesday, May 13, 2008 1:50 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_at_)gmail(_dot_)com>
wrote:
> On Tue, May 13, 2008 at 11:36 AM, Nick Fitzsimons
<nick(_at_)nickfitz(_dot_)co(_dot_)uk> 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(_at_)gmail(_dot_)com
>
> - All models are wrong. Some models are useful.
>
>
> --~------------------------------------------------------------------
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
> To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
> --~--
>
>
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
- michael dykman
- mdykman(_at_)gmail(_dot_)com
- All models are wrong. Some models are useful.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--