From: Kevin on
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
From: Scott Sauyet on
On Jun 4, 10:48 am, Kevin <kevin.m.mered...(a)gmail.com> wrote:
> 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.

--
Scott
From: Thomas 'PointedEars' Lahn on
Scott Sauyet wrote:

> Kevin wrote:
>> 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.

<https://developer.mozilla.org/en/XSLT>

> 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
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: Scott Sauyet on
Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Kevin wrote:
>>> Can't javascript access the XML, and make changes? What's the reason
>>> for using XSLT over writing up a javascript?
>> 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.

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
From: Johannes Baagoe on
Kevin :

> Hi,

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

An XML *document*. Yes.

> Can't javascript access the XML, and make changes?

It can, just like any programming language. Some are better suited than
others, though. XSLT is specifically made for the task of transforming
XML documents in either XML, HTML or plain text.

> What's the reason for using XSLT over writing up a javascript?

One reason is that parsing XML is not quite trivial, with entities,
processing instructions, CDATA sections, etc. A XSLT processor
does it for you automatically, and implementations are usually
efficient. It can even validate your document on the fly against a
DTD or a schema. Why reinvent the wheel ?

On the downside, XSLT may be quite confusing if you are used to more
traditional languages. It is also incredibly verbose, because XSLT
transforms (a.k.a. "stylesheets", but I prefer to use that term to
designate CSS only) are themselves XML documents. This allows the
very powerful technique of using XSLT transforms to produce other XSLT
transforms, but it prevents the transforms from being concise and easy
to understand at a glance. XSLT takes some work to master.

--
Johannes