Hacker News Reader

Comment by snitko | Hacker News Reader

I can kinda understand why XSLT is one of the most expensive (on an intuitive level - as quchen said, it's not clear how the data was obtained for this post). Certain parts of it is a complete brainfuck. I worked on a small opensource project of mine once, where I decided to use XSLT to translate XML to HTML. I din't know much XSLT, so I started reading docs and eventually managed to accomplish my goal. However after struggling with it for a while, I realized it sometimes makes completely no sense. Or, to be more fair, it takes a rather different logic to understand it than I usually apply to programming languages... because, well it's not a programming language.

I only wonder, where is XSLT usually used? Can anyone outline the most typical types of projects and environments?

View on HN

I just had an exam about XSLT, XML Schema, etc... this morning. My take-away is this. Pick any scripting language (python, ruby, php...) + templating engine and you'll avoid the World Of Pain that is XSLT.

XSLT is kind of 'declarative', but it has ifs, switches, ... They probably didn't start out with the plan to implement a programming language with xml tags, but they did. It's horrible.

Edit: XML Schema is horrible as well. This is how you define an element with string content, and one attribute (which is VERY basic):

  <xs:element name="myElement">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute name="myAttribute" type="xs:string" />
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

Just off the top of my head, I could invent something better, like:

  <myElement myAttribute="xs:string">xs:string</myElement>

Ahh yes. I tried writing a schema for my document (ocd here, I like things to be valid), but then I realized that the cost/benefit ratio of this process would be completely unreasonable.

If I had to do it today, I'd probably use DTD to validate the XML tag hierarchy and than use a programming language (with xpath) to validated the attribute and tag contents.

XML Schema tries to validate both the tag hierarchy and the contents, which requires data types and complicated definitions. So much overkill...

DTD and XPath are actually very nice and simple. This is the DTD equivalent of my XML Schema example above:

  <!ELEMENT myElement (#PCDATA)>
  <!ATTLIST myElement myAttribute CDATA>

I could see myself writing a small domain language and translate it to DTD, to make it even nicer.

The way I work around XML schema pain is to use visual tools for it, like the ones in Visual Studio, for example.

Hand editing XML schema files is too much of a pain.

My impression is that this is considered the norm in the XML world: you're supposed to edit it via a specialized editor, not directly as raw text.

XSLT is purely declarative, not just kind of. Those ifs and switches are not imperative constructs, they're evaluated functionally. xsl:if conditionally applies a template, which kind of looks imperative and control-flowy, but is really functional all the way through.

    <xsl:if test="x">template</xsl:test>

is basically this in Lisp:

    (if eval(x) (apply-template template) nil)

And <xsl:for-each> is equivalent to map in Lisp. It's a functional projection, not an imperative loop, even if the syntax looks like that of an imperative language.

RelaxNG would look something like this:

    <element name="myElement">
      <attribute name="myAttribute">
        <text/>
      </attribute>
      <text/>
    </element>

OK, it's not great, but it's better.

I use XSLT for https://emailprivacytester.com/ - The HTML part of the email that it sends is constructed from a small amount of dynamically generated XML, and a static XSLT file:

https://github.com/mikecardwell/email-privacy-tester/blob/ma...

The cool thing is, I initially wrote the application in Perl. I then re-wrote it in NodeJS, but was able to re-use the same stylesheet as it's language independent.

The brainfuck is that it's purely declarative. It represents the transformation of one tree structure to another with no notion of sequential imperatives or associated concepts like variables and mutable state. This has some very distinct advantages: the execution can be very fast and parallelizable and predictable in space and time usage and secure in presenting nearly no attack surface for injections and overflows and such.

This sounds great in theory. But the problem is real world business requirements don't work that way. Real specs are never a straightforward declarative transformation. They always include bells and whistles and rhinestones that don't fit into XSLT. Loop over this set and suppress records where this field matches the previous record (state!), or include pagination, or call somebody's web service in the middle of it to display today's stock price, or grab the user's preferences for colors and time zones. (All real examples from a job I had with XSLT once upon a time.) XSLT doesn't do any of that and isn't supposed to. So you add another layer of data munging in whatever produces the XML before the XSLT operates, or hack it in Javascript afterwards, and either way now you have two problems.

Maybe XSLT skews high for income because it takes huge sums of money to get programmers to even touch the thing.

I had to struggle with XSLT to transform XML into HTML a while back. Since it not intended to be a real programming language, I had trouble making it do the equivalent of something basic like iterating through a collection (recursion, ugh!). I can easily see how it would be a highly-paid skill because the lack of debugging tools (again, it is not a real programming language) made me want to curse MSFT and everyone else who were supporting XSLT at the time (way back) as the Second Coming of content publishing. If you ever want a headache, try reading the XSLT spec.

http://www.w3.org/TR/xslt

Visual Studio (tested version 2010; Express probably won't do it, though) has a pretty good XSLT debugger, which made writing XSLT stylesheets a lot easier when I wrote some a few years ago.

What was wrong with XSLT for-each - which loops over a collection of things quite happily?

>However after struggling with it for a while, I realized it sometimes makes completely no sense. Or, to be more fair, it takes a rather different logic to understand it than I usually apply to programming languages... because, well it's not a programming language.

IIRC, it actually is turing complete (or nearly powerful), and it works in the paradigm of functional programming. Have done a large-ish project with it circa 2002-2004.

>I only wonder, where is XSLT usually used? Can anyone outline the most typical types of projects and environments?

Well, it's used a lot in the enterprise, where there is also a lot of XML.

You use it a lot in structured documentation business (think hardware manufacturer, military, pharmaceutical, ...). Where you publish some xml documentation into serveral output formats like HTML, epub, pdf, whathever..

Because XSLT is used to put a visualization of a data together with an XML-formatted document - very convenient for B2B. You may see content in a browser, and then extract info from the same page without XSLT.

At my workplace all of the legacy projects use XSLT as the templating language for our Cocoon (Java Framework) web applications. Complete and utter clusterfuck, let me tell you...

I worked with XSLT for a few years a while ago, it's functional not procedural and that's the brainfuck you need to get your head around. It was also missing what seemed like basic functionality, like mutable variables.

We used to automatically convert SQL queries into XML using the AS column naming (like SELECT p.Id, p.Name, k.Id [kids\kid\@Id], k.Name [kids\kid\Name] FROM Person p JOIN Kids k ON k.FatherId = p.Id).

Then we could transform server-side to send down the HTML as well as do client-side updates in javascript by sending XML and the running the XSLT clientside to do partial updates (you can specify which part of the XSLT you want to run).

Worked pretty well as at the time, most browsers ran XSLT much faster than they ran Javascript.

I even got a pretty funky pivot table working in it that could handle 10,000s of rows when in javascript it would die after a 1,000 (we're talking IE6/7 era here).

There's actually a Daily WTF article where someone posted Sketchers.com's use of XSLT as a WTF and a lot of people chimed in in the comments that they did this and it was actually really good and not a WTF at all:

http://thedailywtf.com/Articles/Sketchy-Skecherscom.aspx

Note the featured comment was a response from the lead dev!

As for what situations in industry, our use was pretty uncommon as you can see from the WTF, but it's often used to transform XML in one format to another so they can get different systems actually talking to each other.

Reply on news.ycombinator.com