XSLT is a failure wrapped in pain • Hacker News Board

Re: XSLT is a failure wrapped in pain

#81

Post by kabdib » Sat, Dec 06, 2014, 1:38 PM UTC

I once worked on an embedded system with not a lot of RAM or code space, and we were ripping features out to put new stuff in and rewriting things to make new things fit (not a bad practice, re-writing, btw). I wrote some tools to do global optimization at the assembly language level and got back 40K because our compiler was one of those $5000 / seat pieces of crap, and we didn't have a debugger, so object-to-source-line mapping, who needs it?

Anyway, one of the PMs on the project insisted that this choice little hunk'O'hell communicate with the outside world -- at about 2K bits / sec on a good day -- using XML. Because it was standard. Because XML added to anything makes it better, no matter what it is. Because, well, nobody ever saw that traffic except other computers, but XML!

I wanted to kill, kill, kill, but instead I wrote an XML parser (kind of) that fit into about 1K of code. "Don't use entities or CDATA or namespaces," I said, and went away to a better place. I think the PM was happy. That group got sold to a company famous for its 60s-era radios and crappy teevees, and I assume everyone is happy there, because I have not heard a word from them, and XML!

Re: XSLT is a failure wrapped in pain

#82

Post by general_failure » Sat, Dec 06, 2014, 1:42 PM UTC

benihana wrote: post #76

grndn wrote: post #62

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc). I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so yo…

> XML-hating JSON community What are you even talking about? It seems like you think that XML and JSON are two mutually exclusive technologies and that if one is bad, the other is good. Or that if one is used, the other can't be? I don't understand why you even started talking about JSON; the article was about why XML and XSLT suck, not why JSON is superior to them. I'm not really sure what point you're making. JSON…

> JSON is meant to make passing data in JavaScript easier.

No, its not.

Re: XSLT is a failure wrapped in pain

#83

Post by crdoconnor » Sat, Dec 06, 2014, 1:46 PM UTC

ilitirit wrote: post #59

crdoconnor wrote: post #49

Earlier quoted context omitted.

I would use a language that has a decent XML parser (e.g. python + lxml) for input and a decent templating language (e.g. jinja2) for output. Assuming it was a simple transformation, the python parsing code could be under 10 lines. Most of what you wrote would be templating. It would be 98% declarative. If it got complicated though (e.g. you're doing some aggregation or something), the python bit would grow but it pr…

You could do the exact same thing using XSLT. eg. var result = new XSLTProcessor().importStylesheet(xsl).transform(....); It's a bit of a pointless example because it really depends on the transformations you need. I'm sure in some cases XSLT would be better for the job, and in other cases another language. Most of the time it would generally just depend on your environment, available tools and skillset.

>I'm sure in some cases XSLT would be better for the job

In some (simple transformation) cases XSLT would be no worse, but mostly it would be worse. I can't see it being clearer or easier to maintain under any circumstances.

Once your code evolves toward doing anything mildly complicated you'll wish you never made your transformation in xslt.

Re: XSLT is a failure wrapped in pain

#84

Post by boronine » Sat, Dec 06, 2014, 1:52 PM UTC

grndn wrote: post #62

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc). I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so yo…

I'd just like to plug Teleport [0] into the list of reinvented JSON-based solutions. It's in active development :)

[0] http://teleport-json.org

Re: XSLT is a failure wrapped in pain

#85

Post by krig » Sat, Dec 06, 2014, 2:00 PM UTC

grndn wrote: post #62

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc). I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so yo…

In my experience, the people forcing schemas and bloat on JSON are the same people who forced schemas and bloat on XML.

Re: XSLT is a failure wrapped in pain

#86

Post by coldnebo » Sat, Dec 06, 2014, 2:01 PM UTC

grndn wrote: post #62

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc). I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so yo…

Flashback to the early days of XML: "oh god, why would anyone use something as bloated and slow as CORBA to define an interface! Look how simple XML is, and it's human readable!!"

CORBA is laughing its head off: "Who's bloated and overly complex now, eh?"

XML: "Well at least I developed an appreciation of the problem domain... Unlike those arrogant JSON kids"

CORBA: "You were the same way at their age."

XML: "Sure was, gramps!"

(Both chuckle)

Re: XSLT is a failure wrapped in pain

#87

Post by hyp0 » Sat, Dec 06, 2014, 2:01 PM UTC

grndn wrote: post #62

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc). I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so yo…

There have been several JSON transformation tools, but they haven't taken off. (EDIT in general, not just for transformation,) when a task gets too complex for JSON, it's easier to switch to XML. Thus: XML protects JSON.

But I agree there is some pressure on JSON. And if someone can come up with a way to do schema and transformation that isn't complex, it will be adopted like crazy.

Counter-point: (1) all the cool kids use dynamic typing these days, and don't need schema (schema is a form of typing). (2) transformation is easy in fp (which the cool kids are also using), and don't need a separate transformation tool.

Re: XSLT is a failure wrapped in pain

#88

Post by sharpneli » Sat, Dec 06, 2014, 2:04 PM UTC

sly010 wrote: post #79

I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem. I understand writing XSLT and XML Schema can be difficult and I see how typing out XML namespaces can be a pain, but every sentence about XML in that article is a joke. Those quotes are all intended to be funny, not objective. Noone actually brought an objective facts against XML. B…

Or someone else has used it to solve the wrong problem.

Or your customer demands you to solve the wrong problem with XML.

A nice example: Simple configuration files which are best described as simply option=value or maybe json if someone wants to go really wild.

A customer comes and wants configuration files to be XML. Then your sales department agrees and now you have to implement XML files. The end result: Configuration files are no longer easily editable by humans. Yay!

Another example: Someone decided that using makefiles is too hard, so let's make the equivalent but with XML! I'm looking at you ant! Now they're still have the same problems as makefiles but they are much harder to edit.

Re: XSLT is a failure wrapped in pain

#89

Post by patsplat » Sat, Dec 06, 2014, 2:08 PM UTC

sly010 wrote: post #79

I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem. I understand writing XSLT and XML Schema can be difficult and I see how typing out XML namespaces can be a pain, but every sentence about XML in that article is a joke. Those quotes are all intended to be funny, not objective. Noone actually brought an objective facts against XML. B…

Agreed. How much XML was used to introduce DSLs and dynamic typing into Java?

Re: XSLT is a failure wrapped in pain

#90

Post by crdoconnor » Sat, Dec 06, 2014, 2:14 PM UTC

sly010 wrote: post #79

I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem. I understand writing XSLT and XML Schema can be difficult and I see how typing out XML namespaces can be a pain, but every sentence about XML in that article is a joke. Those quotes are all intended to be funny, not objective. Noone actually brought an objective facts against XML. B…

Objective facts:

* XML is complicated enough that its parsers are commonly full of obscure bugs. JSON/YAML doesn't have this problem.

* XML is complicated enough that its parsers can have security vulnerabilities (e.g. see billion laughs for just one). JSON/YAML doesn't have this problem.

* XML is complicated enough that you can create an almost-but-not-quite valid encoding. The (already complicated enough) parsers have to deal with this and the ones that don't are considered broken. JSON/YAML doesn't have this problem.

* XML's complexity does not give you any additional benefit over YAML or JSON. Serializing/deserializing dates as strings is not a problem. It never was.

XSLT is just the shitty icing on the already crappy cake. A committee created a disastrous turing complete programming language to munge this already overcomplicated data format.