
Why I like XSLT - padraic7a
https://guy-murphy.github.io/2014/12/02/why-I-like-XSLT/
======
crdoconnor
>Benefit #1: Portability

You know that a technology has got serious problems when the best thing you
can say about it is "well, it is at least preinstalled everywhere"!

>Benefit #2: Separation of concerns

If you want to put business logic in your XSLT, you can. It is a turing
complete language (unlike, say, jinja2).

True, the language is so terrible that you will _probably_ do everything
possible to avoid putting business logic in your XSLT and that would help with
your separation of concerns. I do not consider this a benefit, however.

>Benefit #3: Transformations

This is not a benefit of the language. This simply what it was originally
intended to do.

>Benefit #4: Focus on API: The focus on XML as the result of a controller
naturally focuses development on the application API

As opposed to other languages where you don't focus development on the
application API?

>Benefit #5: Sand-boxed

Definitely a benefit but far from a unique one. It is also doesn't have
particularly good sandbox implementations: [https://www.mozilla.org/en-
US/security/known-vulnerabilities...](https://www.mozilla.org/en-
US/security/known-vulnerabilities/firefox/)

>Benefit #5: Ease of testing

Compared to what?

~~~
harryf
>>Benefit #1: Portability

> You know that a technology has got serious problems when the best thing you
> can say about it is "well, it is at least preinstalled everywhere"!

... plus it's not even true. For any collection of XSL stylesheets,
representing any kind of real world complexity, the chances you can port them
as-is from A to B is highly dependent on which XSLT features were used (1.0,
2.0 and now 3.0 ), what the XSL processor supports plus "host" framework
idiosyncrasies ( Java, .NET, PHP (
[http://php.net/manual/en/xsltprocessor.registerphpfunctions....](http://php.net/manual/en/xsltprocessor.registerphpfunctions.php)
! , etc. ).

------
serve_yay
Wow, I never thought I'd see someone say that. I found it to be an endless
nightmare when I had to use it. (We thought t would be really cool to store
links and other stuff in XML and then transform that into our ASP.NET pages,
so we could change the XML file without changing the website. It got
complicated over time.)

The point about the syntax is a good one, but I don't like the idea that
people should just equivalently like any syntax that expresses the same basic
ideas.

I can't say why exactly but something just feels fundamentally wrong with
writing code in XML. I felt the same way when I had to write MSBuild scripts,
which are XML. I guess it could be trying to do imperative things in a
declarative language, but that doesn't seem to be a problem for Lispers.

~~~
kiesel
I need to agree. Using XSLT to write a XML -> HTML website is not a good idea
- at least when a bunch of developers maintain it over time.

From the ground up, I admit I like XSLT. But: maintaining large sites that
inherit templates (call-templates and apply-templates) and style through
<xsl:include/> and <xsl:import/> over lots of files tends to become a template
mess. After a while only the experienced devs are able to maintain the
templates.

Then, it's a functional language, where lots of things are overly complicated
to do; you can do just everything, but that doesn't mean you should.

~~~
donum
Why is it a bad idea?

I work together with a bunch of developers on a website that renders its HTML
output with XSLT. What you address is architecture.

What we basically did is we have one XSL file for each "element". Elements
are: button, image, headline, etc. Each of those elements inputs "our own" XML
syntax with wisely chosen defaults (some HTML attributes like class,id,style
get just passed through) and outputs Twitter Bootstrap HTML. Writing
responsive websites in our framework is extremely easy. So each element has a
XSL file where the magic happens, an XML file with documentation and tests and
additional files like scass/css/js files with the same name. Accessing them is
extremely easy when you use something like Sublime Text (what we all do).

All those different templates get written into just one XSL file automatically
with the help of node.js' gulp.

The website gets delivered in Apache Cocoon which has a pipeline concept
similar to gulp. Once a page got rendered, it is cached until the next update
(except for pages with dynamic content of course).

The whole frameworks documentation is basically a website written in this
framework with automated tests.

We use XSLT 1.0 + EXSLT and have written around 30 (EXSLT) functions to make
sure everything works like we expect.

Everybody in our team loves it.

~~~
kiesel
Probably true; the architecture we had in the team was nonexistant, so it
turned into a mess... XSLT then has nothing to improve upon.

If you start out "right", you probably will be able to enjoy XSL.

------
elmarschraml
XSLT is one of those cases where the idea and the intention is great, but the
actual implementation is horrible.

I would love to see someone propose a modern alternative to XSLT, that works
for the same use cases, but avoids XSLTs mistakes.

~~~
FrobeniusTwist
I hear you, but if your assessment is based on XSLT 1.0 (which is likely,
since 2.0 was not very widely implemented) you might reconsider. The
differences between 1.0 and 2.0 are so stark and significant that they're
hardly comparable. They both use the same syntax (XML-based, which is an
understandable turn-off), and the processing model is essentially the same,
but the inclusion of a real type system in XPath/XSLT 2.0, and some badly-
needed features that needed to be kludged in 1.0 (for-each-group being the
most conspicuous, IMO) makes a real difference. I think it's a shame that the
very real limitations of XSLT 1.0 continue to be imputed to 2.0 (and the
impending version 3.0), since, if you're working with XML at all (which maybe
you shouldn't be, but that's another issue), XSLT is a great example of Alan
Kay's requirement that "simple things should be simple, and complex things
should be possible."

~~~
JadeNB
> I hear you, but if your assessment is based on XSLT 1.0 (which is likely,
> since 2.0 was not very widely implemented) you might reconsider.

 _Are_ there now any free, portable XSLT 2.0-compatible processors (ideally,
that match xsltproc in ease of use)? Surely no-one is comforted by "this
version fixes the problems of the previous one, but you can't use it"!

EDIT: OK, Saxon (I won't link to it because I've always felt a little skeeved
out by their "let's make people pay for schema awareness" business model,
however legitimate it is)—it's even available through MacPorts. I don't know
if I just never knew about that, or if the XSLT 2.0 support wasn't always
free.

------
bri3d
I interned at a company with an XML+XSLT based MVC framework once. I actually
thought it worked really well and generally agree with the article. A lot of
more "modern" template and transform solutions are aiming for the same goals:
sandboxed, side-effect free, limited logic, and so on.

I especially like the power of combining XSLT with Batik and FOP. You can take
backend data and present it as an interactive table, a visualization, or a PDF
report really easily.

I will say that the syntax is _awfully_ obtuse, though. I find that support
for various powerful-but-obtuse 1990s/2000s solution stacks splits along an
IDE-user line: those who use IDEs are generally comfortable working with XML
and XSLT in Java while text-editor devotees tend to hate that class of
solution.

~~~
kevin_thibedeau
I got tired of updating my resume in Word then Manually generating PDF and
massaging a plain text export into something decent. Now I write one document
in ReST that is converted to Docbook (with XSLT) then run the Docbook through
XSLT to get the meat of a DocX, XSLT to get an XSL-FO derived PDF, and XSLT to
get an HTML derived plain text. Obtuse but powerful.

~~~
kstrauser
I get the same results with Markdown and Pandoc. Check it out sometime.

~~~
mercurial
I have a ReST -> rst2html -> wkhtmltopdf pipeline. The advantage is that I can
use a standard CSS.

------
jimfuller2014
I can say with high confidence that I've probably written more XSLT then any
of the commentators here ... respect completely their right to
hate/love/ignore any tech, but many of the comments here are based on very
little fact.

* first bugbear - XSLT is not an implementation of lisp (or insert lang here), we shouldn't care if it implements said language well or not

* XSLT is extremely well (saxon) implemented in some processors and poorly in others ... unsure what that has to do with the language itself.

* XSLT has more implementations then a lot of other popular languages (Ruby, Perl, python come to mind), that doesn't make it better (or worst) then those languages ... its just a fact.

* there are no security vulnerabilities in the design of XSLT that I am aware about (well, there are, and most certainly are in implementations, but at that level I can call out issues with every language and its processor(s)) ... stating it is insecure by design is rubbish

* anyone using XSLT v1.0 should know that there has been, for years, an XSLT v2.0 production ready version in the form of saxon-ce (w/ appropriate open source license) ... I can't explain why folks insist on using XLST v1.0, some are doing so cause they can't migrate to XSLT v2.0, many of them are unaware of new options.

I can understand why folks find XSLT hard, or hurts their brain or makes them
want to cringe at the mention of an angle bracket ... teaching basic
programming idioms is hard for most people, learning fp principles is even
more of a bender (esp if you come from OO world) ... XSLT template matching is
a powerful mechanism which allows one to perform transformations with a
succinct set of matching rules ... but yes it is verbose and like many
languages, XSLT has its ugly points to the language.

If you are allergic to angle brackets, then any language that uses them is
going to be anathema to them, but every person I've known who have learned
XSLT became a better programmer for it. Thats my own personally biased single
data point observed 'fact'.

~~~
Tloewald
I don't think learning XSLT made me a better programmer, but it is an
_amazingly_ useful tool for dealing with large amounts of XML (which is what
it was designed for). That said, the way XPATH works is -- to put it mildly --
counter-intuitive.

My biggest gripe with XSLT is debugging. It's just not very much fun. Insofar
as it forces you to reason very carefully about your code, that's probably
good practice if you haven't already had plenty of practice -- e.g. developing
websites before we had decent browser consoles, or writing INITs and TSRs in
the 80s.

~~~
qaribou
We were probably using it for very different things (I used it to render my
HTML for a PHP site), but I actually found the debugging part to be a huge
advantage of xslt. The errors I had relating to basic config and encoding
issues were all big headaches, sure, but debugging issues caused by my own
incorrect assumptions about how my data was structured was great -- I never
felt lost and every message gave me a clear idea what I needed to look at.

------
smhinsey
XSLT definitely has its flaws and I'm not currently using it, but I am
currently building an app whose UI is heavily data-driven, meaning a screen
might display a dynamic list of items, each with a totally different
editing/viewing/previewing experience. You can dance around the edges of this
with current templating engines to the point where you have a workable
solution for a specific case, but honestly nothing really compares to the
generalizing power of template matching where all you'd need to do is wire up
the appropriate XPath selector to a new template and there you go. This level
of abstraction does not even appear to be on the radar of the templating
libraries I'm familiar with but I'd love to hear about those that do support
it if they exist.

------
aboodman
The opposing viewpoint:
[http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of...](http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/)

------
catshirt
used a ton of xslt. it's great for what it's good for (transforming xml). of
course, if i had to do it all over again i wouldn't be using xml in the first
place.

------
baldeagle
I bought into xslt2... which I think was only ever implimented in the saxon
parser, written by they guy that wrote large chunks of the spec. My chain was
simple, MS Access DB -> XML (via hand written vba) -> parser -> 4 documents
with information that was consistent. I then handed it over to a programmer to
replace the Access DB / XML / Parser with the server versions, and he never
did get it quite right. For my next project I chose JSON, on the idea that a
beautiful solution doesn't mean much if it can't be productionized. Still sad
about xslt though, lots of potential for making good looking pdfs and webpages
that were consistent.

------
qaribou
I'd recently experimented with XSLT for a PHP site's templating engine, after
having ignored it since learning it about a decade ago. I swapped out all PHP
code to load a bunch of variables for building a big DOMDocument tree in-
memory, then applying my XSLT to that to build the rendered HTML. Once I
stopped trying to stick a bunch of <xsl:if> and <xsl:for-each>es all over the
place, and took a compositional approach to templating where I simply defined
the <xsl:template>s I needed and then put <xsl:apply-templates> where I wanted
them to go, it actually worked extremely well. All my templates were nicely
organized, and I'm far happier working in XML than HTML, with all it's wacky
requirements with some tags needing to be closed and others not. It's just the
little things that really made me happy -- sticking my fontawesome icons in
with an <i class="fa fa-pied-piper" /> instead of <i class="fa fa-pied-
piper"></i> always brought a smile to my face. It also made testing nice and
fast since it's pretty easy to save the XML I want to transform as a file
outside of my PHP app, and just xsltproc it from a terminal until I get it
working how I want it.

The big pain points were all around the library support. The XSLT lib was
generally fine, but the XML processing PHP provides was rubbish. The main
complaint I heard was that even PHP5.5 wouldn't support outputting as html5,
and you need to manually just echo out a '<!DOCTYPE html>' to work around
that. I couldn't just import HTML directly from elsewhere as rendered by my
CMS into my document tree either - it needed to have string literals of tags
concatenated to it just to work. The sheer number of piddly little flags that
are barely documented but you need to get exactly right in order for it to
work at all was a big nuisance too. I also needed to turn off all parser
warnings so it wouldn't barf on reading html5 docs, and when a big advantage
of the language is that you can be strict about your markup, it seems quite
silly to have to turn off warnings.

Looking back on it, none of my problems were really with XSLT as a language,
just with how it's implemented in various languages. I feel like a lot of
people got turned off when they learned about it in school, and consequently
nobody was interested in doing a good job of implementing its supporting
libraries in any language.

------
fubuu
For me XSLT (I mean 2.0 and above) is awesome technology for current web
environment. There are a lot of markup languages with which I can for example
create graphics (SVG) and use it inside PDF (thru formatting objects (XSL-
FO)). I can store complex application configurations inside Excel (OOXML) and
transform it to xml and validate it (and then generate data file for db). Or I
can manage language translations in excel file and merge them to individual
properties files. I can also use powerful XSLT 2.0 inside browser with Saxon-
CE. There are really lots of use cases for XSLT. I must mention that I use
this technology with Apache ANT and this combination saved a lot of my time!
In this way it is possible to do sophisticated automations. I don't know how
many people use it but it is possible to have a build file and some xml
configuration. In main ant target you specify xslt task (input=xml
configuration, output=build file) and subsequent ant task which triggers this
generated build file. This technique gives great flexibility! Of course when
working with XMLs you need a good IDE!

------
whichdan
I'm very interested in working on a Javascript framework where you work
directly with XML (for data and event binding) and let XSLT handle
transforming it to HTML -- imagine React, except you work with XML instead,
and treat it as an interface for your HTML.

Email me if you'd like to chat about it!

~~~
HillRat
You can do some interesting things by embedding XSLT and XML into script tags,
then wiring them up with MutationObservers -- I just hacked together a quick-
and-ugly example of a Knockout-style reactive interface, and it works just
fine. The big drawbacks are that your interface is still pretty noisy (though
you can preprocess some of those XML headers and CDATA section tags into the
page if necessary), and using XPath or DOM functions to update the XML isn't
really very fun. Still, though, it'd be interesting to see what could be done
with it, even if it's probably not a front end I'd like to wrestle with for
daily development.

~~~
whichdan
The cool thing is that jQuery/Sizzle can use normal DOM selectors on an XML
document, so there is a little flexibility there, and like you said,
MutationObserver is pretty excellent.

Getting rid of the noise is my biggest concern. Ideally, a developer should
never have to know about or touch the HTML that's being generated. It's a
lofty goal, for sure.

------
yegor256a
Totally agree, XSLT is a great instrument and it can/should be used in a
browser too, see [http://www.yegor256.com/2014/06/25/xml-and-xslt-in-
browser.h...](http://www.yegor256.com/2014/06/25/xml-and-xslt-in-browser.html)

~~~
thangalin
The following 45 lines of XSL code transforms a simple XML document into XHTML
DIV tags that mirror the input structure:

    
    
        <xsl:stylesheet version="1.0"
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    
        <xsl:output
          indent="no"
          method="html"
          doctype-system="about:legacy-compat"
          encoding="utf-8"/>
    
        <!-- Action parser that responds to HTTP requests. -->
        <xsl:param name="action" select="'do.dhtml'"/>
    
        <xsl:template match="/">
        <html>
          <head>
            <meta charset='utf-8'/>
            <title>Title</title>
    
            <link rel='stylesheet' type='text/css' href='css/common.css'/>
          </head>
          <body>
            <xsl:apply-templates/>
            <script type='text/javascript' src='js/common.js'></script>
          </body>
        </html>
        </xsl:template>
    
        <!-- Make the document complete with div elements and classes. -->
        <xsl:template match="*">
          <div class="{local-name()}"><xsl:apply-templates select="node()|@*"/></div>
        </xsl:template>
    
        <!-- The 'id' attribute indicates a link. -->
        <xsl:template match="*[@id]">
          <div class="{local-name()}"><a
            href="{$action}?action={local-name()}&amp;id={@id}"><xsl:apply-templates
              select="node()|*"/></a></div>
        </xsl:template>
    
        <!-- Retain the attributes (except if named "class"). -->
        <xsl:template match="@*">
          <xsl:if test="name() != 'class'"><xsl:copy-of select="."/></xsl:if>
        </xsl:template>
    
        </xsl:stylesheet>
    

CSS is then used to customize the presentation layer. For example, all the
pages in the following website (click only "Next" and Safari is broken) are
completely client-side XSLT, but use an XML document as a starting point:

[http://djarvis.bitbucket.org/xml/](http://djarvis.bitbucket.org/xml/)

The pie chart on the following page was also generated using client-side XSLT:

[http://djarvis.bitbucket.org/xml/resources.xml](http://djarvis.bitbucket.org/xml/resources.xml)

The only "trick" that was required was to load CSS (and some JavaScript) based
on the current filename in the URL:

[http://djarvis.bitbucket.org/xml/js/common.js](http://djarvis.bitbucket.org/xml/js/common.js)

Most people write one XSLT page per web page to transform, but by using
structured DIVs with classes that correspond to the XML element names, only
one general-purpose XSL page is required.

This demonstrates the separation of content (XML) from presentation
(XHTML/CSS).

~~~
julie1
Give me an input, the expected output, and I will show you I can do a more
readable shorter and easier version of the transofrmation with jquery. The
XSLT is so unreadable it requires comments.

I did once a less than 2k library in js that loaded the TTML markup in an
hidden div and would show it on an HTML 5 video player with extra formatting.

Why would someone need XSLT in 2014? It was a failure in 2000.

------
joseacta
What I like about them the most of the separation. You're actually
manipulating the data (XML) and displaying it to end user in HTML without
going through the formalities of coding.

Being using them since 1999 too. Still use them today although more work is
being done with JSON/JS.

~~~
dragonwriter
> What I like about them the most of the separation. You're actually
> manipulating the data (XML) and displaying it to end user in HTML without
> going through the formalities of coding.

How is writing XSLT _not_ coding?

~~~
crdoconnor
It is. That's the truly awful thing about it - it is a turing complete
language that kind of pretends not to be.

This is why templating languages are better at helping you maintain separation
of concerns - they physically won't let you put business logic in the view
layer because they aren't turing complete. XSLT will.

~~~
dragonwriter
Not being Turing-complete doesn't prevent you from putting business logic in
the view layer, it just means that you are likely to run into some limitations
doing that (as there are some computable functions that can't be done in the
templating language so that you probabaly will run into some business logic
that can't be done in it.)

This might further discourage putting business logic in the view layer, but,
OTOH, it just as easily result in developers starting to go down the logic-in-
view road, running into things that don't work there, and then ending up with
_some_ business logic in the view and _some_ business logic in more
appropriate layers.

And there's really nothing inherent in view transformations vs. business logic
that necessarily makes the latter sufficiently served by a weaker
computational model than a Turing complete one, so not having a Turing
complete language for the view can result in view transformations in other
layers or constrain the flexibility of presentation if that isn't done.

~~~
crdoconnor
>And there's really nothing inherent in view transformations vs. business
logic that necessarily makes the latter sufficiently served by a weaker
computational model

There is. View transformations are essentially configuration. As such, the
ideal language for describing them is declarative.

To keep declarative languages clear, you need to make them _not_ be turing
complete. If they are turing complete they become unpredictable and difficult
to understand.

Business logic requires turing completeness and usually requires mutable
state.

------
monksy
I hate to promote my own site
([http://theexceptioncatcher.com](http://theexceptioncatcher.com)) but I found
that it made it a lot easier to separate the design of the site from the
content. Most of my websites rarely ever change, so having a dynamic site is
over kill. XSLT/XML helps to keep it as a static site, and I have the
opportunity to change/fix the design at will.

Also, I've managed to setup a system to generate my resume via an XML/XSLT
transform. I haven't published how I do that (or the public version [which is
out of date]).

It's a tool and it can be very useful if you understand what you're doing.
Additionally, there is Unix support for XSLT processing.

~~~
brianpgordon
There are _so many_ template engines out there. Using XSLT to generate HTML is
one of the most obtuse, obsolete ways you could possibly generate static
pages.

[https://en.wikipedia.org/wiki/Comparison_of_web_template_eng...](https://en.wikipedia.org/wiki/Comparison_of_web_template_engines)

~~~
monksy
The problem with a lot of those options is that the transformation happens on
the server. I'm not really interested in doing that, with exception to
googlebot. I want to keep everything static. It's hard to exploit a website
that is all static.

~~~
dflock
That just means that you'd run them over your source locally and upload the
static output to the web server. This is what most static blogging engines,
like Jekyl, Pelican etc... do.

~~~
phkahler
Sounds like an extra step to me ;-)

------
bokchoi
The improved syntax is interesting. Are there any better front-ends to XSLT? A
quick google turned up SLAX, but I wonder if there are others.

[https://github.com/Juniper/libslax](https://github.com/Juniper/libslax)

------
Theyeard
One interesting use-case is having an Atom feed and HTML page at the same
time. See source code here: [https://curiosity-driven.org/](https://curiosity-
driven.org/)

------
Animats
I've used XSLT for APIs that return XML. This allows looking at the output of
the API in a human-readable format. This is convenient as a debug tool, and
anything that returns an XML page should have a link to the XLST for it.

~~~
jahewson
Alternatively, you could build your API using a human-readable format and
dispense with the XSLT. For more complex debugging there's always the Accept
header in HTTP which allows you to return a HTML page for browsers using your
server-side template engine of choice.

------
g8oz
So much promise but a clunky abomination imo. I personally wasted a lot of
time with it about 10 years ago. I've noticed that technologies that are
easier to work with in a text editor eventually win out.

------
sideproject
ahhh, XSLT, haven't heard that name in awhile.

For my CS honours thesis, I created XSLT debugging program - my research paper
is here

[http://ww2.cs.mu.oz.au/~jbailey/papers/wise.ps](http://ww2.cs.mu.oz.au/~jbailey/papers/wise.ps)

I miss it :) but now that I'm doing lots of web development & javascript, I do
wonder that it is somewhat "slow" or "heavy" than other approaches.

Nonetheless, it was an awesome experience diving deep into the technology.

------
tomlongson
If I never heard the acronym XSLT again it would be too soon.

------
intrasight
First, I don't understand what's with the complaints about the syntax. It's
just a flavor of XML. If you work with XML all day, then XSLT looks just fine.
But even if you don't like the syntax, so what - there aren't any alternatives
to XSLT.

Those of you that know and love XSLT will understand when I say I wish I could
be cast into an alternative universe where XSLT continued to be mainstream.

I'll continue to leverage this power-tool (and get paid handsomely by by
clients for wielding such power) for the rest of my career.

~~~
crdoconnor
>First, I don't understand what's with the complaints about the syntax. It's
just a flavor of XML.

People who hate XSLT are not usually fans of XML either.

>But even if you don't like the syntax, so what - there aren't any
alternatives to XSLT.

There are hundreds. Simply use any normal programming language (javascript,
python, perl, ruby, etc.) with a templating language (handlebars, jinja2,
etc.).

The results will be much cleaner, easier to debug, and will remain cleaner as
your transformations get ever more complex (code has a habit of doing that).

~~~
Mikhail_Edoshin
Yep, everyone hates XML and then gets excited over "microformats" or
"components" :)

These hundreds of languages have no pattern matching but all have mutable
state; XSLT is declarative and this removes a ton of complexity. If you had a
bunch of related tables would you process them as Python dicts and arrays or
rather load them in an RDBMS and write SQL instead? Especially as the
transformations get more complex?

~~~
crdoconnor
>Yep, everyone hates XML and then gets excited over "microformats" or
"components" :)

The 'exciting' thing about microformats was that it got you slightly higher
positioning in SERPs. I don't know if that's true any longer. That was hardly
a benefit of the language design.

I've never heard of components.

>These hundreds of languages have no pattern matching but all have mutable
state

There are hundreds of bad languages. I wouldn't defend any of them. Most
widely used languages have some form of decent pattern matching, though.

Mutable state can cause headaches, but if you want to use a functional
language to help solve that - these days you're spoilt for choice. Most modern
languages can be written in a functional style also, if that's your thing.

>XSLT is declarative and this removes a ton of complexity.

The OP made this claim by comparing it favorably to a javascript program that
parsed HTML using regular expressions. Which makes me wonder (and shudder
about) just what you and the rest of the XSLT defenders are actually comparing
it to. And also why you seemingly haven't seen or used any good parsers or
templating languages.

>If you had a bunch of related tables would you process them as Python dicts
and arrays or rather load them in an RDBMS and write SQL instead

That would depend entirely upon what I was doing and why. I have done both in
different contexts because they had different trade offs.

>Especially as the transformations get more complex?

SQL is capable of handling a great deal of complexity (more than xslt
certainly), and its declarative nature certainly nets you a lot of things for
free (less code, faster queries, no deserialization/serialization overhead),
but it still has its limits. Yes, for _really_ complex transformations I would
probably write them in python and not SQL.

~~~
Mikhail_Edoshin
How could you miss components, the new web revolution? :) Here it is being
presented by Google:

[https://www.youtube.com/watch?v=2toYLLcoY14](https://www.youtube.com/watch?v=2toYLLcoY14)

It's basically custom HTML tags like:

    
    
      <tabs>
        <tab>Alpha</tab>
        <tab>Bravo</tab>
        <tab>Charlie</tab>
      </tab>
    

and some JavaScript library ("a new type of library for the Web") that
processes these custom tags to display tabs on a web page.

I'm talking about pattern matching for templating rules; e.g. I want to handle
a "value" token differently depending on whether the parent is a "field" or a
"value-list" With XSLT I do this with a pattern: "field/value" vs "value-
list/value". It's very clear and very efficient behind the scenes (about as
speedy as a regex). I'm not sure I can do it in Python as easily.

As for parsers: parsers are a good thing, certainly, but look at what they do:
they take an unstructured sequence of symbols and try to recover the hidden
structure of it using a set of grammar rules. The end result is a tree that
still contains the original sequence but dissects it into a hierarchy of
discovered non-terminals.

Doesn't this look familiar? It's an XML document. XML documents are basically
preparsed sequences or serialized parse trees. Maybe they have been parsed
already by a specialized parser; or maybe the structure was added there
manually when we marked up a text in a natural language; or maybe the sequence
was generated by a machine in the first place and we just retained the
original structure. What XML does is that it saves the result so there's no
need to parse the same sequence again.

(Well, there is; we still need to deserialize the XML document and to
interpret certain sequences as strings and another as numbers or dates and
this is also parsing; but the serialization notation is much simpler than the
grammars that were involved to parse or build the original tree.)

This is why _parsing_ HTML is a waste of time regardless of whether we do this
with regular expressions, recursive descent, Earley, LALR, Tomita, PEG, or
whatever parsing technology we like :) It has been parsed already; we only
need to deserialize it, and this is a trivial task that has been solved long
time ago. (Well, maybe not with HTML, because somehow it's important to accept
broken HTML and this may require a full-fledged parser and then some.)

------
jlebrech
components could be achieved using xslt, you have a high level app spec, and
you transform all the components.

------
snarfy
> He can have it.

~~~
mlvljr
"XSLT? I has it."

[http://www.youtube.com/watch?v=CjWYbcbpiWA](http://www.youtube.com/watch?v=CjWYbcbpiWA)

:)

------
malandrew
repost:
[https://news.ycombinator.com/item?id=8695638](https://news.ycombinator.com/item?id=8695638)
but there was no prior discussion there.

~~~
padraic7a
Ah my apologies, I should have done a better search. Thought it would be worth
posting since I have seen it discussed a bit in my area of work [libraries /
digital humanities].

xslt really seems to get acceptance from non-programmers who want it to
perform a specific functions [like convert some hand crafted xml into html]
and hatred from programmers who point out lots of problems with it as a
language. I guess I would never even have thought of it as a language until I
heard these complaints - I saw it more as a toolkit for, well, performing very
specific functions.

~~~
malandrew
No problem. It's good to point out the reposts since it helps identify urls
that should be investigated to figure out why the deduping algo didn't catch
it.

Good article though.

