No. That myth has been decisively addressed by Erik Naggum about 12 years ago. His summary:
> They are not identical. The aspects you are willing to ignore are
> more important than the aspects you are willing to accept. Robbery
> is not just another way of making a living, rape is not just another
> way of satisfying basic human needs, torture is not just another way
> of interrogation. And XML is not just another way of writing S-exps.
> There are some things in life that you do not do if you want to be a
> moral being and feel proud of what you have accomplished.
Please read his posting/rant for the arguments. Dude. (I'll just tell you to search for "naggum xml", there are more than enough copies in circulation, and you'll find a few more postings by other people.)
Now, as for XSLT: The big problem is the hairy syntax. It is really (at least) two languages (the XML tags, and the query language that is used inside selectors). In effect, you are writing at least three languages completely intermixed in a single file: the output language (most often some XML or HTML variant), the XSLT tag language (another XML format), and the XSLT query language (an incredibly limited ad hoc micro-language inside some XML attributes).
XSLT is a very limited language, as opposed to Lisp macros, which can use the entire Lisp language.
And yes, I have used XSLT in my job, and I do have reason to think that the XSLT-stylesheets I wrote have an acceptable quality. However, I know that I could have done their job better if I could have used some structured data, an HTML formatter, and a real programming language.
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.
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.
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.
Dude, XML is just s-exprs and XSLT is macros.
> XML is just s-exprs
No. That myth has been decisively addressed by Erik Naggum about 12 years ago. His summary:
> They are not identical. The aspects you are willing to ignore are > more important than the aspects you are willing to accept. Robbery > is not just another way of making a living, rape is not just another > way of satisfying basic human needs, torture is not just another way > of interrogation. And XML is not just another way of writing S-exps. > There are some things in life that you do not do if you want to be a > moral being and feel proud of what you have accomplished.
Please read his posting/rant for the arguments. Dude. (I'll just tell you to search for "naggum xml", there are more than enough copies in circulation, and you'll find a few more postings by other people.)
Now, as for XSLT: The big problem is the hairy syntax. It is really (at least) two languages (the XML tags, and the query language that is used inside selectors). In effect, you are writing at least three languages completely intermixed in a single file: the output language (most often some XML or HTML variant), the XSLT tag language (another XML format), and the XSLT query language (an incredibly limited ad hoc micro-language inside some XML attributes).
XSLT is a very limited language, as opposed to Lisp macros, which can use the entire Lisp language.
And yes, I have used XSLT in my job, and I do have reason to think that the XSLT-stylesheets I wrote have an acceptable quality. However, I know that I could have done their job better if I could have used some structured data, an HTML formatter, and a real programming language.
Tell any lisp programmer he doesn't get first-class functions and has to use nothing but macros, and he'll run screaming in horror.
XML and XSLT are analagous to s-exprs and macros, to say they are "just" those things is willful ignorance of a whole boatload of complexity.
Good, so I'll replace the '<' in XML with '#:-D' and the '>' with '%:-/'
Or replace indenting levels with the XPath of where it belongs and make order optional
Syntax matters.
REALLY? http://en.wikipedia.org/wiki/XSLT#Example_1_.28transforming_...
I want to enter this piece of evidence into the trial:
Comma separated string parsing XSLT: http://stackoverflow.com/a/2850181/92493
2 replies →
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.
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.
1 reply →
> 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.
3 replies →
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.
2 replies →