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

61–70 of 157 posts

Re: XSLT is a failure wrapped in pain

#61

Post by ohyesyodo »

jgalt212 wrote: post #52
ohyesyodo wrote: post #46

Okay, so what am I supposed to use if I want to transform a XML file from one format to another because two different systems needs XML for input /output and they have different fixed formats?

I don't know if you're trolling, but here's how I'd do it in Python import xml.etree.ElementTree as ET tree = ET.parse('data.xml') new_tree = my_transform(tree) new_tree.write("output.xml")

I'm not sure if you are trolling, but you left out the actual transform. In my experience, XSLT feels optimized towards transforms, which most other languages aren't. I also dislike XSLT, but whenever I do things like this in Python, C# or C++ it tends to get more messy then my XLTS when the transforms are nontrivial.

Re: XSLT is a failure wrapped in pain

#62

Post by grndn »

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 you can mix different schemas, a standard for binary JSON, a standard for JSON-encryption, and so on.

"Those who cannot remember the past are condemned to repeat it."

Re: XSLT is a failure wrapped in pain

#63

Post by raverbashing »

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.

Good, so I'll replace the '' with '%:-/'

Or replace indenting levels with the XPath of where it belongs and make order optional

Syntax matters.

Re: XSLT is a failure wrapped in pain

#64

Post by geonik »

moonshinefe wrote: post #38
geonik wrote: post #36

Those who rant about XML and XSLT know nothing about what they talk about. 50% of our server's behavior (200,000 Java LOCs) is orchestrated declaratively by a small number of XML files that use around 30 custom namespaces. These are 1. parsed on server startup for setting up persistence, business rules, REST endpoints etc 2. transformed by XSLT to a) produce nice HTML documentation, including DOT class diagrams b) ge…

I'm afraid your argument of "It worked for us" and "it only uses a small number of files with 30 custom namespaces" pretty much is the most unconvincing argument I've ever heard. In fact, the latter point is one of the reasons most people like to avoid XML.

"the latter point is one of the reasons most people like to avoid XML"

And these are exactly those who will never "get" that XML is much more than a data container for tree-like structures. They should stick to JSON or CSV for that matter.

Re: XSLT is a failure wrapped in pain

#65

Post by Arwill »

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…

Its a generational thing. Programmers grown up on JavaScript will prefer JSON. Its not a unique phenomenon. My guess is the noSQL was born out of fact that many young programmers simply don't know how to write SQL, if they don't know/want to use SQL and rely on ORM mapping alone, then they can as well do away with SQL databases too.

Re: XSLT is a failure wrapped in pain

#66

Post by dalke »

duncanawoods wrote: post #20

I believe the fundamental pain of xslt was... that it was an FP language. When teaching XSLT, the difference between those who said "its elegant" vs. those who said "its pain" - is whether the individual could grok FP. Angle bracket overload, verbosity of end tags, library support, poor whitespace handling, namespace pain were all obstacles too but it was FP that made standard problems feel like math proofs and for d…

I really enjoyed proving theorems for analysis - I have an undergrad degree in mathematics - but not so much algebraic proofs. Where does that put me? :)

In any case, we know that algebraists who program also use Maple, Magma, Mathematica, R, and Sage, or even straight Python, C, etc. FP languages are a minority even in the professional mathematics world.

Re: XSLT is a failure wrapped in pain

#67

Post by Havvy »

qwerta wrote: post #15
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.

I am sorry but Javascript is not much better than XSLT. Horrible legacy technology full of bugs nobody was bothered to fix.

JavaScript isn't full of bugs nobody has bothered to fix. It's full of specified behavior that cannot be fixed without breaking backwards compatibility. That said, the issues are well known and actually bypassable.

Whether you should be using it for the problem XSLT tries to solve is another question. Probably not, since there are other templating languages.

Re: XSLT is a failure wrapped in pain

#68

Post by Mikhail_Edoshin »

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…

So the problems are real, it's just that XML and XSLT (and now JSON schema et al.) solve them badly (to your taste)?

Re: XSLT is a failure wrapped in pain

#69

Post by patrickg »

justincormack wrote: post #58
patrickg wrote: post #12

Earlier quoted context omitted.

apples and oranges? There is no other way of encoding structured documents these days than XML. Like it or not, XML is the de facto standard for data exchange (export from databases, product information software,....) XML might be overengeneered (which, except for a few things I don't agree with), but there is currently no alternative for it.

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 other formats) are not an issue for me b) There is a very nice toolchain for XML, including formatters, tranformation tools, database publishing tools (my very own: https://speedata.github.io/publisher/index.html) and many others. I have not found such a toolchain for other formats.

Re: XSLT is a failure wrapped in pain

#70

Post by carsongross »

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://vimeo.com/29348322

Post reply on HN