XSLT is a failure wrapped in pain • Hacker News Board

Re: XSLT is a failure wrapped in pain

#121

Post by skywhopper » Sat, Dec 06, 2014, 4:22 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…

Ultimately, I think the problem is that everyone thinks we need to be able to do all the same things with structured, hierarchical data that we can do with normalized, relational data. And it's like going from 2-D to 3-D. Things don't get just twice as complicated, they get exponentially more complicated as the problem-space and schema complexity grows.

Thus any toolset that tries to address relationships, schemas, searching, and grouping in an XML/JSON type data format is going to be exponentially more complicated than RDBMSes and SQL.

Re: XSLT is a failure wrapped in pain

#122

Post by scrollaway » Sat, Dec 06, 2014, 4:25 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…

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

The JSON approach does not give you everything-and-the-kitchen-sink. A lot of people consider that a feature.

If you want to do schema validation on top of json messages, you're free to do it when you receive them - the data format does not prevent you from that, it merely does not advocate and standardize one-way-of-doing-it.

The fact the various existing json schema solutions have not found a leader amongst themselves speaks loudly to the fact that it's a useless feature for most people, and the format is better off without it. Whatever the RFC would come up with, people would find fault in it... so if most users don't care, why force one solution over any other?

GP is foolish to think XML does not have benefits over JSON, but you're a lot more foolish to think those benefits (the ones you advertise, anyway) should be part of the language. You say "As JSON grows...", but that's exactly the thing: it doesn't grow. It's a simple data format and needs no new feature. Would trailing commas and comments be nice? They sure would. But we can live without them in the format itself... let alone schema validation which can be done externally.

Re: XSLT is a failure wrapped in pain

#123

Post by blablabla123 » Sat, Dec 06, 2014, 4:29 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?

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

Having written tranformations in Python that needed to carry that information... How do you do that in XSLT? (And do you think it's worth writing new code in XSLT?)

Re: XSLT is a failure wrapped in pain

#124

Post by [deleted] » Sat, Dec 06, 2014, 4:30 PM UTC

personZ wrote: post #118

crdoconnor wrote: post #107

Earlier quoted context omitted.

>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 "begin…

It's a glorious time in software development when people who make and use trivial web apps think that their domain dominates, and that their superficial knowledge reigns supreme.

[deleted]

Re: XSLT is a failure wrapped in pain

#125

Post by ogig » Sat, Dec 06, 2014, 4:34 PM UTC

cenazoic wrote: post #120

Anyone tried the "XSLT-powered open source content management system", http://www.getsymphony.com/ ?

I've made several small sites with it. It used some great ideas like the data model been totally flexible while easy to use and xml + xslt as server side templating was nice to use. The in-browser developer tools were good too.

Unfortunately there were also a bunch of bad points that never got fixed. Breaking changes for pluggins exhausted the small contributors community. I think the project is basically dead at this point and I've moved to another cms for small sites. (Keystone.js)

All in all, if i were to rewrite symphonycms now, i would drop xslt in favour of jade or something less anoying to writte in.

EDIT: I've been browsing symphonycms repo after writting this and it's untrue to say the project is dead since Brendo is still actively commiting.

Re: XSLT is a failure wrapped in pain

#126

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

scrollaway wrote: post #122

personZ wrote: post #106

Earlier quoted context omitted.

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…

> 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. The JSON approach does not give you everything-and-the-kitchen-sink. A lot of people consider that a feature. If you want to do schema validation on top of json messages, you're free to do it when you receive them - the data format does not prevent you from that, it m…

>GP is foolish to think XML does not have benefits over JSON

I am? What benefits would those be?

Re: XSLT is a failure wrapped in pain

#127

Post by based2 » Sat, Dec 06, 2014, 4:36 PM UTC

cenazoic wrote: post #120

Anyone tried the "XSLT-powered open source content management system", http://www.getsymphony.com/ ?

http://cocoon.apache.org/1365_1_1.html

Re: XSLT is a failure wrapped in pain

#128

Post by tree_of_item » Sat, Dec 06, 2014, 4:36 PM UTC

matwood wrote: post #112

Arwill wrote: post #65

Earlier quoted context omitted.

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.

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. Until that whole leaky abstraction problem kicks in.

The idea behind doing away with the SQL database is to remove the leaky abstraction of an ORM, by making the object model the true shape of the data and not a wrapper over SQL.

Re: XSLT is a failure wrapped in pain

#129

Post by snarfy » Sat, Dec 06, 2014, 4:38 PM UTC

I like this one:

>“XML combines the efficiency of text files with the readability of binary files”

One dirty thing about XML is that it appears human readable, but it is not human writable. You'll see something in the XML that you think you can change, but now it doesn't validate anymore after you change it using a text editor. You need an XML editor that understands XML validation to make edits. If I cannot use a basic text editor, it's not basic text. If it's not basic text, it's no better than any other binary protocol, albeit a very inefficient one.

Re: XSLT is a failure wrapped in pain

#130

Post by felixgallo » Sat, Dec 06, 2014, 4:51 PM UTC

crdoconnor wrote: post #109

coldnebo wrote: post #95

Earlier quoted context omitted.

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 obje…

As an example of the deceptive simplicity, could you please describe how many bytes are required to deserialize numbers represented in JSON? Note: answer is not 2,4, or 8.