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

71–80 of 157 posts

Re: XSLT is a failure wrapped in pain

#71

Post by chinpokomon »

I've seen XSLT done well, and I've seen the mess it can be when written by someone with only a passing knowledge. As a consultant I usually have dealt with the latter, and that usually goes hand in hand with a poorly designed XML schema.

One space that XSLT can demonstrate its strength is when transforming some horribly serialized interoperability data structure. If the system from which you are receiving data, produces terse XML, you aren't going to solve anything by rewriting the upstream system to produce equally lousy JSON. If you don't have the ability to fix the upstream service to produce better structured data, XSLT and XPath are wonderful tools to morph it into something more manageable. That transformation process is better written with XSLTs than it is in trying to do the same thing by slurping the data directly into some business object and trying then to work with a bad model. Don't go down the path of "garbage out, garbage in."

If you have access to both sides of the process, it might be worth rewriting the upstream system, but when working with a legacy system XSLT might be the best glue technology in your arsenal.

Re: XSLT is a failure wrapped in pain

#72

Post by boomlinde »

patrickg wrote: post #26
boomlinde wrote: post #19

Earlier quoted context omitted.

The site in question lists several alternatives, some of which are widely in use especially in cases where XML falls short: brevity, fast to parse, easily readable... Most of all, calling it the de facto standard is either dishonest or clueless.

I am working for many years in the publishing business (dealing with structured documents, product data etc.). I can tell you, that all of my customers are more open XML than any other document formats (there exist none as suitable for the job). You can call me clueless or dishonest, I don't care. I can only share my experience with the topic. You don't have to believe me.

Your customers in the field you work in, perhaps, but it's hard to tell that's what you mean when you write data exchange. It's a wide field that is not limited to the publishing business or your customers.

Re: XSLT is a failure wrapped in pain

#73

Post by tete »

cat-v is actually pretty nice. A lot of their stuff looks a bit like "Oh my god, why" and "That person just doesn't have a clue". I thought the same with so many technologies that I got into. I always thought KISS was nice and I always felt like abstraction is a good way to reach that KISS.

Turns out it is not. Things can fail, really badly even and they do fail, really often even, even when there are companies with big pockets standing behind it and then good luck debugging the mess. This is true even for really proven technologies, but might be less obvious on those.

At some point when you are good at some technology, even if it's really popular, mainstream, be it some big SQL database (yes, all of PG, SQLite and MySQL even though I love some of those), C, C++, Java, C# or Python/Ruby/Perl/Node.js you will constantly end up with the implementation of the underlying technology.

I am not saying XSLT or any of the above don't have their use cases, but actually that a lot of them are over-engineered. Using most of these technologies I know there are issues, send bug reports and patches and hey, things get fixed really quickly. That's all good and you never can fully avoid these things, but the more simpler you get the less there is that end up biting you and causing you to start out with lets say you having your SASS to CSS compiler having an issue, digging deeper through every library finding a GCC bug or whatever. Such things happen.. more often than one would think. So based on developer pay and the issues it causes (often being a blocker for a whole team) that's actually a really big problem.

Re: XSLT is a failure wrapped in pain

#74

Post by skrebbel »

carsongross wrote: post #70
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 took a KI(RF)SS stab at a JSON schema description language, attempting to avoid the insanity of the XML world but still provide a bit of structure for JSON, a while back: http://jschema.org/ Haven't touched it in a few years, but I think the core idea is sound: as much schema as can be packed into 15 additional productions beyond the original 15 in the JSON spec. I wrote a typeloader for Gosu based on it: http://vi…

I once braindumped a similar idea on https://github.com/eteeselink/relax-json (inspired by RELAX NG, one of the few great things to come out of the XML world).

A core difference between it and your JSchema is that it, itself, is not JSON - just like XML, I don't think JSON makes for a good format to write down schema definitions. In fact, I don't think JSON is very human friendly at all[0], which is OK for a data interchange format, occasionally read by humans but hardly ever written by hand.

I did not further develop RELAX JSON, however, when I realized that TypeScript interface definitions[1] are a great JSON schema language:

    enum Color { Yellow, Brown }; 

    interface Banana {
        color: Color;
        length: number;
    }

    interface FruitBasket {
        bananas: Array;
        apples:  Array?;
    }
It's best to use interfaces and not classes, because interfaces allow for optional fields (with the `?` suffix), which is pretty common in APIs and wherever JSON is used.

I will write a validate-JSON-with-TypeScript-type-definitions checker as soon as I find a need for it. Open to ideas here, guys! (or alternatives)

[0] Compare gruntfiles to webpack configs (tl;dr: they're JSON and JS-that-returns-an-object, respectively. the latter allows code, comments, unquoted keys, etc etc).

[1] http://www.typescriptlang.org/Handbook#interfaces

Re: XSLT is a failure wrapped in pain

#75

Post by lafar6502 »

xml is technically a superset of JSON, just can't imagine any clear advantage of JSON vs XML - it's the same league, just some minor syntactic differences. And what is the end of the story for JSON, is just a beginning in XML: the concept of namespaces is powerful and totally foreign to JSON. Then XML Schema - another job well done and poorly mimicked in some JSON libraries. XSLT just builds on these concepts and is not a general purpose tool - don't see a reason to have strong opinion about something so narrowly specialized.

Re: XSLT is a failure wrapped in pain

#76

Post by benihana »

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 is meant to make passing data in JavaScript easier. It's a necessary tool for interactive, JavaScript-heavy web frontends. I'm not sure why there's so much condescension in your post for JSON and its tooling. I'm just a bit confused; it comes off like you have a personal stake in XML and you find any mention of JSON, even obliquely, as offensive.

There's no reason that XML and JSON can't both be tools we use when the situation calls for it. This kind of dogmatic defense or condemnation of technologies offhand doesn't really do the HN community or the programmers at large any good.

Re: XSLT is a failure wrapped in pain

#78

Post by justincormack »

patrickg wrote: post #69
justincormack wrote: post #58

Earlier quoted context omitted.

databases are not structured documents , you can export them eg in JSON perfectly well. Or for that matter in SQL as is the usual practise. Marked up structured text is a different matter, XML still has a use case there.

I was a bit unclear. When I get database dumps, I get them as Excel files or as an XML document. Most of the times the documents I get are hierarchically structured. Yes, JSON could be fine as well. But it simply lacks a standard toolchain which XSLT ans its ilk proides. I am not trying to defend XML in any way. I just want to say the two things: a) my customers never deal with JSON, but often with XML, so JSON (and…

But XML does not map well to a database dump. A database is a set of sets of tuples. It is not generically hierarchical. It maps to a set of csv files say, as a transfer medium, but it is designed to be manipulated through relational calculus, which is not easily mapped to xslt.

You are using tools not because they map well to the problem space, but because they are the tools you have, which your customers want, and which you are familiar with, but that does not mean they are actually mapping well to the domain.

Re: XSLT is a failure wrapped in pain

#79

Post by sly010 »

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. Because they can't. The fact is it is widely used in many places. Anyone tell me an alternative to serialise an object tree where you also need to preserve ordering and type information, you need to store text longer than one line, or you just need to store any kind of formatting information. (and yes, you can use JSON to do that, but the resulting document will be 5x longer)

(meta: Funny quotes bashing useful technologies is the cat video equivalent of HN. Last week's article beating OOP was the same pattern.)

Post reply on HN