Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XSLT is a failure wrapped in pain

harmful.cat-v.org

Post reply on HN
Print view View original

91–100 of 157 posts

Re: XSLT is a failure wrapped in pain

#91

Post by crdoconnor »

ilitirit wrote: post #60
paulsutter wrote: post #8

JSON/Javascript is just easier to learn and work with than XML/XSLT. For starters, you don't need to learn a special language that you'll never use for anything else. Just in case you /do/ need to use XML every day: the primary benefit of XSLT is that it lets you avoid using XML libraries to munge some XML. Because the XML libraries are so horrendous to use from any language.

> JSON/Javascript is just easier to learn and work with than XML/XSLT. Unfortuntely running Javascript on the back-end for this purpose is not something most companies do.

You're joking, right? There are JSON libraries for every back end language and ecosystem you could imagine.

Re: XSLT is a failure wrapped in pain

#92

Post by [deleted] »

praptak wrote: post #27
radicalbyte wrote: post #9

The problem with XSLT, XML, SOAP, WS-* is that the community is driven by vendors with deep pockets who use their power to kill interoperability. Imagine LISP, but in the hands of Sauron or Palpatine. That's the XML group of technology.

> Imagine LISP, but in the hands of Sauron or Palpatine. Common Lisp?

[deleted]

Re: XSLT is a failure wrapped in pain

#93

Post by crdoconnor »

sharpneli wrote: post #88
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: Configur…

In my experience

* Configuration files are best made with YAML (it's the most human readable).

* APIs / other forms of serialization/deserialization over a network are best done with JSON (chop it in half and it will fail fast unlike yaml. still fairly readable tho).

* Programming languages (like ant) should not be written in either one ever (fortunately I've never heard of a YAML or JSON based language).

* XML does a bad to terrible job of all three.

Re: XSLT is a failure wrapped in pain

#94

Post by crdoconnor »

hyp0 wrote: post #87
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 k…

>There have been several JSON transformation tools, but they haven't taken off. When a task gets too complex for JSON, it's easier to switch to XML. Thus: XML protects JSON.

Uh, no. In general if you're sensible enough to use JSON as a data interchange format, you're probably sensible enough to use a real programming language to do transformation.

Re: XSLT is a failure wrapped in pain

#95

Post by coldnebo »

hyp0 wrote: post #87
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 k…

There is a lot of confusion between typing systems, metatyping systems (that can implement arbitrary type systems) and the transport representation of such systems.

I agree with your counterpoints, but the cool kids are still having issues with transport representation of arbitrary types. Sure (eg Ruby) can use Kernel dump and load to marshall arbitrary types, but what happens when the other end doesn't have the type loaded or available?

Ouch, maybe we should invite Java Enterprise Beans to the party to comment on the semantics of distributed types?

JSON is currently deceptively simple precisely because its wire representation (with simple types) is equivalent to its type definition which can be directly evaled in js to produce a memory instantiation. But none of that holds in the general case... Try for example marshalling a JSON object with a tree structure.

Maybe we end up going in Alan Kay's direction, where we stop trying to send representations across the wire and just send code... But that too was tried in the past. It has other limitations.

It's complicated.

Re: XSLT is a failure wrapped in pain

#96

Post by donum »

bibonix wrote: post #3

XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better

Since two years I am working full time on a website which gets rendered via XSLT (via Apache Cocoon). When I joined, it was kind of a mess and I had a hard time understanding XSLT and the templates written.

Just recently I had the chance to do a rewrite. What I did is I created "my own HTML". Basically every module of Twitter Bootstrap has it's own XSLT template. That means you have a very easy XML "HTML" syntax, but the output is Twitter Bootstrap. And every piece of output HTML is defined just once in the whole application so it's easy to maintain.

With the help of XSLT you can abstract a lot of things. One example: I have an element called . It can contain up to 12 elements. if I set the @size attribute to one of the columns, the @size attribute for the others will be calculated automatically and the output matches the Twitter Bootstrap CSS classes.

I have to say, I love it. I can't imaging writing the whole mess of Twitter Bootstrap plain HTML in a template anymore.

Re: XSLT is a failure wrapped in pain

#97

Post by crdoconnor »

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…

>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).

JSON schema:

Validing schemas is not as nearly important for JSON as it is for XML. JSON's relative simplicity the problem of "almost-but-not-quite" valid encoding mostly goes away.

As a result, not many people use JSON schema.

Even when I work with XML I very rarely come across code that performed actual XML validation. Most people would just wing it and hope nothing broke. That's the first dirty secret of XML validation.

The second dirty secret is that if you are consuming an API that provides invalid XML (a common occurrence), you just deal with it and try to make it work. XML validity be damned.

Collection+JSON:

Literally never heard of this. Don't need it either. Once the JSON is deserialized you can use the language's own tools (and a combination of lists/arrays + maps). So what's the point? I don't miss XPath or XQuery.

Siren:

An solution attempting to solve a non-problem copied from a solution from the XML world that didn't solve a problem either.

Re: XSLT is a failure wrapped in pain

#98

Post by crdoconnor »

krig wrote: post #85
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.

Fortunately they're usually ignored.

Re: XSLT is a failure wrapped in pain

#99

Post by DennisP »

peteretep wrote: post #13
raverbashing wrote: post #4

Earlier quoted context omitted.

My definition of powerful and elegant is lisp XML is just death by overengineering

> My definition of powerful and elegant is lisp Dude, XML is just s-exprs and XSLT is macros.

Tell any lisp programmer he doesn't get first-class functions and has to use nothing but macros, and he'll run screaming in horror.

Re: XSLT is a failure wrapped in pain

#100

Post by craigching »

VMG wrote: post #16

Since it is the hot topic of the day, let me add this perspective: http://www.snoyman.com/blog/2012/04/xslt-rant.html Quote > I'm not even talking about the hideously verbose syntax, or the completely obtuse data model. The fact that you can't know what any single line of code does without reviewing every other line in the program makes this language an abomination.

That link is on the page ;)
Post reply on HN