XSLT v. Javascript

[Kevin]

Hi,

I learned about XSLT from Wikipedia and W3C. As I understanad XSLT, it
transforms an XML file based upon XSLT's rules.

Can't javascript access the XML, and make changes? What's the reason
for using XSLT over writing up a javascript?

Thanks,
Kevin

 

[Scott Sauyet]

I learned about XSLT from Wikipedia and W3C. As I understanad XSLT, it
transforms an XML file based upon XSLT's rules.

Can't javascript access the XML, and make changes? What's the reason
for using XSLT over writing up a javascript?

If you're working in an application that only works with Javascript
enabled, then there aren't many advantages. But there are good
reasons for making applications that are accessible to as wide an
audience as possible. If you want to do that, then the application
should still function if the user does not have JS enabled. This
means that the application should present its data in a useful manner
to users without JS. If that involves transforming XML data, then
there is a strong argument for doing so server-side. You can do this
in various ways, including with server-side JS. But the tool designed
specifically for this job is XSLT.

XSLT involves a very different mind-set than JS and will take some
unlearning of imperative techniques (imagine not being able to change
the value of a variable!) but it is a very useful skill.

One hybrid approach I've used on some projects involving XML data
sources is to build an application that works without JS by using XSLT
transforms on the server, but then uses JS when it's available to
enhance the page in ways that bypass those transforms and use the XML
directly or via other transforms to JSON formats. This works
reasonably well, but is a little tedious as you need to maintain both
the XSLT transforms and the JS ones.

 

[Thomas 'PointedEars' Lahn]

I learned about XSLT from Wikipedia and W3C. As I understanad XSLT, it
transforms an XML file based upon XSLT's rules.

Can't javascript access the XML, and make changes? What's the reason
for using XSLT over writing up a javascript?

If you're working in an application that only works with Javascript
enabled, then there aren't many advantages. [...]

Since there are client-side XSLT implementations in current browsers,
both with and without scripting, that cannot be correct.

One hybrid approach I've used on some projects involving XML data
sources is to build an application that works without JS by using XSLT
transforms on the server, but then uses JS when it's available to
enhance the page in ways that bypass those transforms and use the XML
directly or via other transforms to JSON formats. This works
reasonably well, but is a little tedious as you need to maintain both
the XSLT transforms and the JS ones.

Given those client-side implementations, it might not be necessary to use
XML/XSLT *and* JSON. However, it should be possible to use XSLT to convert
XML to JSON both server-side and client-side, so you would not need to
maintain both.


PointedEars

 

[Scott Sauyet]

Given those client-side implementations, it might not be necessary to use
XML/XSLT *and* JSON.  However, it should be possible to use XSLT to convert
XML to JSON both server-side and client-side, so you would not need to
maintain both.

That's an interesting possibility I never considered. Usually these
solutions were my fixes to JS-only applications, making them more
accessible, and I stopped at a working solution. But going one step
further and replacing the XML-parsing code from the client-side
scripts in favor of a client-side XSLT use could well be more
maintainable. Next time I face this issue, I will definitely remember
your idea.

 

[Scott Sauyet]

Scott Sauyet :

Why ? Are there any significant browsers who cannot understand a
`<?xml-stylesheet type="text/xsl"?>` instruction ? E.g., that fail
to render pages likehttp://baagoe.com/en/RandomMusings/javascript/?
(take a look at the source)

Also, many browsers provide a XSLTProcessor object you can invoke in
javascript to process, e.g., documents obtained by XMLHttpRequest. That
is very handy to interact with XML databases using, e.g., XQuery,
which is a *much* nicer language than SQL.

These are valid points, although I don't really know how universally
available an XSLTProcessor is. Are they available on commonly used
mobile phones, for instance?

But there are, IMHO, still several reasons for preferring to do this
on the server. First, although we can generally assume that client
resources are cheaper than server ones for our application, if this
processing can be done once and cached, then the overall processing
required is significantly reduced.

Second, in my experience, these transforms most often significantly
reduce the size of the data stream. Doing the transform on the server
can greatly reduce our bandwidth. Of course there are time when the
reverse is true, especially when it involved converting data-centric
XML to display-ready HTML, but in my environments, this is rarely the
case. YMMV.