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

141–150 of 157 posts

Re: XSLT is a failure wrapped in pain

#141

Post by lowmagnet »

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 only use of XSL in my past was to take XMLthat's already in the right structure and simply iterate via apply templates. XSL excels this sort of simple template work.

So does mustache, with a bit less resistance/overhead.

So does Polymer if you make your xml tags into web components and apply them. It also has all of the benefits of Polymer's isolation.

I think xsl was and is a good idea. I just think that other things have come along that are easier to get into.

Re: XSLT is a failure wrapped in pain

#142

Post by Mikhail_Edoshin »

snarfy wrote: post #129

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

How do you manage to change C or Python source code? Omit a ";" in C or ":" in Python and it will refuse to compile.

Re: XSLT is a failure wrapped in pain

#143

Post by pm24601 »

The problem with most tools is that they go through the "bright and shiny" stage:

  "New tool - cool! Lets use it on EVERY problem."
And are thus misused.

XSLT exists for inter-organizational data transfer and transformation. Don't use it for any other situation.

XML is a good (not perfect) persistent data storage mechanism where you need the data to outlast the program that created it.

I go into more explanation here: http://sworddance.com/blog/2014/12/06/xml-is-not-bad-just-mi...

Lets not blame a tool that was misused.

Re: XSLT is a failure wrapped in pain

#144

Post by Mikhail_Edoshin »

ilitirit wrote: post #45
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.

> Most of all, calling it the de facto standard is either dishonest or clueless It is in fact the de facto standard in the publishing industry. The "other" format is of course PDF. Maybe all of this will change when we have more technologies that support formats that can handle mixed content as easily as XML.

Does anyone use Microsoft XPS? It looked rather interesting; like PDF without any interactivity (except for links) and with special support for publishing (color management, job tickets, etc.). And internally it is a collection of XML docs and binary data zipped together into a single file; pretty neat, must be easier to use in automated workflows.

Re: XSLT is a failure wrapped in pain

#145

Post by dragonwriter »

patrickg wrote: post #12
raverbashing wrote: post #4

Earlier quoted context omitted.

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

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.

> XML might be overengeneered (which, except for a few things I don't agree with), but there is currently no alternative for it.

There's perhaps no general alternative to it that covers all of the things XML tries to do; there are lots of specific alternatives that cover specific things that XML tries to do. The complaint against XML isn't that there is a better general replacement so much that there is a better replacement for each (or at least, very many) of the applications and that trying to shoehorn all of them into a single solution has costs that outweigh the benefits.

Re: XSLT is a failure wrapped in pain

#146

Post by pm24601 »

Mikhail_Edoshin wrote: post #142
snarfy wrote: post #129

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

How do you manage to change C or Python source code? Omit a ";" in C or ":" in Python and it will refuse to compile.

I normally don't do +1 on a one-line answer but this was the perfect rebuttal.

I wonder how s/he does handle that pesky ';'

Re: XSLT is a failure wrapped in pain

#147

Post by patrickg »

Mikhail_Edoshin wrote: post #144
ilitirit wrote: post #45

Earlier quoted context omitted.

> Most of all, calling it the de facto standard is either dishonest or clueless It is in fact the de facto standard in the publishing industry. The "other" format is of course PDF. Maybe all of this will change when we have more technologies that support formats that can handle mixed content as easily as XML.

Does anyone use Microsoft XPS? It looked rather interesting; like PDF without any interactivity (except for links) and with special support for publishing (color management, job tickets, etc.). And internally it is a collection of XML docs and binary data zipped together into a single file; pretty neat, must be easier to use in automated workflows.

I can't answer the question but anyway:

None of my customers have ever asked for that. I have not seen a printing house that demands XPS. So I doubt that it plays any role in the market (Germany here).

Re: XSLT is a failure wrapped in pain

#148

Post by coldnebo »

crdoconnor wrote: post #140
coldnebo wrote: post #139

Earlier quoted context omitted.

The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler. Here's a very simple example of marshaling comparing Marshal dump and load in Ruby using YAML, vs. custom JSON marshalers: http://www.skorks.com/2010/04/serializing-and-deserializing-... Note that the post shows a tree structure in YAML because Marshall gives it to you for free (synonymous wi…

>The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler. Which makes perfect sense. If you cut everything down to bool, null, number, string, list and map you can represent anything and you get to remain language agnostic. Dates can be encoded as strings and so can most of the other more 'awkward' types. This is additional work, but it's not that…

> you can represent anything

If you represent something, you need to interpret it later... i.e. both client and server need the same interpretation in order to avoid errors.

> Dates can be encoded as strings and so can most of the other more 'awkward' types.

You say 'encoding', I say 'serialization'.

> It's not that complicated

It isn't as long as you use the same platform for encoding and decoding.

Maybe our experiences are different. I remember one time I had to unencrypt a string in Ruby that had been encrypted in Java. I thought, this will be simple, it's a standard AES encryption, I'll just stuff the string into the corresponding Ruby object and decrypt! I mean, both of these objects were implemented according to the same industry standard right? Boy was that a learning experience. :) Framing, padding and seeding was not implemented the same way -- it was left as a platform implementation detail that only someone trying to integrate across systems would ever notice.

Re: XSLT is a failure wrapped in pain

#149

Post by personZ »

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…

It's a simple data format and needs no new feature.

XSLT was developed entirely independently of XML. XML Schemas were developed entirely independently of XML.

XML itself is absurd simple. It is the epitome of simple. But you build an ecosystem of tools and standards around it. And that is of course already happening in JSON -- JSON Schemas, for instance, are now a thing.

Re: XSLT is a failure wrapped in pain

#150

Post by Mikhail_Edoshin »

patrickg wrote: post #147
Mikhail_Edoshin wrote: post #144

Earlier quoted context omitted.

Does anyone use Microsoft XPS? It looked rather interesting; like PDF without any interactivity (except for links) and with special support for publishing (color management, job tickets, etc.). And internally it is a collection of XML docs and binary data zipped together into a single file; pretty neat, must be easier to use in automated workflows.

I can't answer the question but anyway: None of my customers have ever asked for that. I have not seen a printing house that demands XPS. So I doubt that it plays any role in the market (Germany here).

Thanks, that's informative. I haven't seen it used much either; the only real use I saw (aside from viewing) was an XPS printer driver for a Canon inkjet printer. (I've also heard that it produced better results than the standard driver, but have no first-hand experience.)
Post reply on HN