XSLT is a failure wrapped in pain • Hacker News Board

Re: XSLT is a failure wrapped in pain

#101

Post by microtonal » Sat, Dec 06, 2014, 2:34 PM UTC

tete wrote: post #73

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…

but the more simpler you get the less there is that end up biting you

And increasing the probability that you invent the wheel, badly. I have been using libxml and libxslt for years and as far as I remember I never encountered a bug. Both projects have been developed for years and is used by a gazillion other projects.

It is many times more likely that you will be bitten by a bug in your own custom configuration file parser than e.g. in libxml2.

I am not arguing for or against XML, but code reuse. Simplicity also means not reinventing the wheel and keeping your own projects simple by leveraging existing, good, libraries.

Re: XSLT is a failure wrapped in pain

#102

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

boronine wrote: post #84

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

That actually looks pretty nice.

Re: XSLT is a failure wrapped in pain

#103

Post by hobs » Sat, Dec 06, 2014, 2:34 PM UTC

nly wrote: post #51

What's with linking to an old "XML sucks" page with no content, insight or original thought? Is it bash time? On XSLT: find something that fills its role completely, with the same level of tooling, and then have a rant about inferior tools being popular, until then it doesn't really matter if it sucks.

If you refresh HN regularly, you will see that really often. People are just gaming the community for a few upvotes or views as far as I can tell.

I see this timeline all the time: 1. User posts article about xyz technology 2. User posts article negating post 1 3. Most boring shitstorm every occurs 4. karma karma karma

Re: XSLT is a failure wrapped in pain

#104

Post by brokentone » Sat, Dec 06, 2014, 2:45 PM UTC

Reminds me of the person (people, team, etc) who decided it was a good idea to code websites in XML + XSLT. Because XHTML is just not good enough. The most prominent of these (I'm shocked it's still this way) is http://www.skechers.com/

Re: XSLT is a failure wrapped in pain

#105

Post by jffry » Sat, Dec 06, 2014, 2:45 PM UTC

crdoconnor wrote: post #90

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…

YAML allows deserialization into arbitrary native types, which most definitely is [1] an issue (see: the flood of Rails/YAML vulns a while back)

[1] http://blogs.teamb.com/craigstuntz/2013/02/04/38738/

Re: XSLT is a failure wrapped in pain

#106

Post by personZ » Sat, Dec 06, 2014, 2:47 PM UTC

crdoconnor wrote: post #90

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…

If we eliminated everything where implementations have had obscure bugs or security vulnerabilities, there would literally be nothing left.

XML's complexity does not give you any additional benefit over YAML or JSON.

This is so incredibly wrong, on every level, that it belies belief and reads like something you would come across on a "beginning programmers" forum. As others have said, JSON/YAML thus far have seen limited usage (no, that configuration file on your app is not a complex example). But as it grows people are starting to ask questions like "Gosh, wouldn't it be nice if my perimeter or the source system via a metadata file could validate the JSON passed to us". "Wouldn't it be nice to be able to convert from one JSON form to another."

And the exact same complexity is arising...poorly, and with the same hiccups that the XML system went through.

I mean some of the comments are incredible. Like "JSON is simple enough that errors aren't big" -> Hey, sorry that those bank transfer got lost, but it turns out that we mistyped the account number field name and the destination system just ate it. Json.

¯\(°_o)/¯

Sorry that the dates are completely wrong, but all of those years of discovery about time zones and regional settings...just make it some sort of string and they'll figure it out.

¯\(°_o)/¯

Re: XSLT is a failure wrapped in pain

#107

Post by crdoconnor » Sat, Dec 06, 2014, 3:02 PM UTC

personZ wrote: post #106

crdoconnor wrote: post #90

Earlier quoted context omitted.

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…

If we eliminated everything where implementations have had obscure bugs or security vulnerabilities, there would literally be nothing left. XML's complexity does not give you any additional benefit over YAML or JSON. This is so incredibly wrong, on every level, that it belies belief and reads like something you would come across on a "beginning programmers" forum. As others have said, JSON/YAML thus far have seen lim…

>If we eliminated everything where implementations have had obscure bugs or security vulnerabilities, there would literally be nothing left.

The point is that by eliminating this data format you get rid of those obscure bugs and security vulnerabilities and you lose nothing of value doing it.

>This is so incredibly wrong, on every level, that it belies belief and reads like something you would come across on a "beginning programmers" forum.

I wouldn't find this quite so pathetic if I didn't have to school you on XML parser vulnerabilities.

>As others have said, JSON/YAML thus far have seen limited usage

What are you smoking? JSON is everywhere these days. More commonly used in new web APIs than XML for sure.

>But as it grows people are starting to ask questions like "Gosh, wouldn't it be nice if my perimeter or the source system via a metadata file could validate the JSON passed to us". "Wouldn't it be nice to be able to convert from what JSON form to another."

The first I hear occasionally, but it honestly isn't ever a problem. You can put validation in the code that parses the JSON. Invalid date sent? Return an error when your javascript/python/java returns an error parsin it. Name too long? Ditto. You don't need additional outside validation if your programming language doesn't suck.

The second question isn't one I have ever heard in 12 years of software development. Generally you want to do something useful with JSON input. That useful thing isn't normally "make more JSON that looks slightly different".

>And the exact same complexity is arising

Nope. Ain't no billion laughs vulns in any JSON parsers that I know of. No subtle parser bugs causing fucked up behavior down the line either.

>I mean some of the comments are incredible. Like "JSON is simple enough that errors aren't big" -> Hey, sorry that those bank transfer got lost, but it turns out that we mistyped the account number and the destination system just ate it. Json.

If you mistyped the account number on your banking system and it got caught by an XML validator your systems must be fucked.

That's the worst excuse for XML I've ever heard: that your systems are so terribly programmed that you must find user errors via validation of your data interchange format. Jesus.

>Sorry that the dates are completely wrong, but all of those years of discovery about time zones and regional settings...just make it some sort of string and they'll figure it out.

Essentially, yes. ISO 8601 and you're done. Where's the problem?

Re: XSLT is a failure wrapped in pain

#108

Post by ramped » Sat, Dec 06, 2014, 3:04 PM UTC

hobs wrote: post #103

nly wrote: post #51

What's with linking to an old "XML sucks" page with no content, insight or original thought? Is it bash time? On XSLT: find something that fills its role completely, with the same level of tooling, and then have a rant about inferior tools being popular, until then it doesn't really matter if it sucks.

If you refresh HN regularly, you will see that really often. People are just gaming the community for a few upvotes or views as far as I can tell. I see this timeline all the time: 1. User posts article about xyz technology 2. User posts article negating post 1 3. Most boring shitstorm every occurs 4. karma karma karma

I think you just described every discussion medium on the Internet.

As a reddit refugee, I was hoping for a little more on HN.

Re: XSLT is a failure wrapped in pain

#109

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

coldnebo wrote: post #95

hyp0 wrote: post #87

Earlier quoted context omitted.

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…

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

It's not deceptively simple. It's just simple. The fact that it can be evaluated in JS is incidental to its use as a general purpose format for serializing data structures.

>Try for example marshalling a JSON object with a tree structure.

I've done this lots of times. I don't see any issue with it.

Re: XSLT is a failure wrapped in pain

#110

Post by Allan_Smithee » Sat, Dec 06, 2014, 3:16 PM UTC

gioele wrote: post #56

How many languages can tell you that byte X of output has been generated from byte Y of input going though such and such steps? When programming in XSLT it is great to fire up a debugger (let's say oXygen), run your transformation, click on the wrong output and being able to go step-by-step backwards . How many languages designed before 1999 (yeah, XSLT is 15 years old) can claim to be able to do so?

Mercury (1998).