The link in the linked article that is meant to link to the evidence that Torvalds is wrong, instead links to itself. Inadvertent self-reference in a conversation about modern data structures is a very bad sign.
If 99% of XML uses make a bad name for the rest of them, the problem is with XML. "XML" is not a spec - it's a culture, and the culture is rotten, and Linux calls it out. Even if there's the occasional good use of XML, it pales among all the other horrible uses -- and every rare good use of XML is not actually better than the alternatives.
Author blames Linus for using "m" to signify "meter" instead of "miles" as being incomplete. Well, every nontrivial important measure is in MKS, in which "m" is properly distinguished from "mm", "cm", "km". (And by the way, did the post mean nautical miles, or ground miles?)
I agree that confusing miles and meters is probably hard, especially to people exposed to a sane measurement system. However, his point about durating being represented in a non-standard format is a valid one. Also I'm very confused why temperatures are given in Coulomb.
> However, his point about durating being represented in a non-standard format is a valid one.
ISO 8601 does specify a standard for duration. I've only ever seen it used in vCalendar entries - I've seen DD:HH:MM:SS everywhere else. So while it is an ISO standard, much like OOXML, almost no one actually uses it - in which case I wouldn't be hard on Linus for not using it.
> Also I'm very confused why temperatures are given in Coulomb.
Me too, but it's still more sane than giving them in Farad like some people do :)
"So while it is an ISO standard, much like OOXML, almost no one actually uses it..."
That should be a subject of education. I never new about that ISO 8601 until I seen an xkcd caricature, whereas I should have known only that standard notation in my education!
I work with Java application servers and I loathe XML. Why Ant uses an XML? Why couldn't it be a simple DSL? <copy to=...>" is not needed, really.
Property files go a long way to help differentiate it. XML has invaded almost all aspects of Java programming, but it seems things are getting better with Java EE 6 and the web services annotations for example, but application servers and framework authors need to stop cramming XML this and XML that for configuration files.
It is funny that he says that the problem with XML is bad programmers because the first design goal of XML[1] was -
"XML shall be straightforwardly usable over the Internet."
The bewildering number of XML specifications to simply use an XML file makes it daunting for anyone to learn to use XML "properly". The XML standard today is hardly anything but "straightforward".
Additionally, it is not a particularly efficient format for machines nor for humans to use. Saying that a good editor can solve everything is a very flippant way of addressing the common challenges with editing maze-like XML documents.
Perhaps Linus didn't elaborate on the context of his criticism for the XML format, but it resonated with a lot of programmers not because of his popularity but they had faced similar painful situations before.
The article says "XML files should standalone". Most XML files are not readily readable unless you have looked at the XSD or copious amounts of documentation, if someone documented it, to understand the options, their meaning and their values. And, usually, XSDs are referred as schemas, just saying.
Subsurface XML's are, to me at least, reasonable. Does it follow a spec? No. Can I, a human, look at it and say that 'm' stands for meters? Sure, the context is "humans diving" so 'm' can stand for miles. Being a human means I can process contextualized information.
Man, I really hate XML and have some dislike for its defenders.
I don't get why this was written. Linus said something obviously hyperbolic about a language with many generally accepted pitfalls. This author clarifies that it isn't impossible to work with, has some applications and that using it well is better than using it poorly.
What I'm trying to say is: is this just making a general and well-worn case for XML or is there a point relevant to Subsurface? I'm sure I could find a shallow remark made by this author and write 1000 words of qualification around that too. Right now, all I see is someone responding to a statement from a big name for attention.
Is there a argument hidden in there about XML's relative ease to work with compared to other formats, either programatically or as a user? Any points on if XML is the right or wrong choice of tool for subsurface?
The closest thing I see is a throwaway comment about an instance where CSV files also benefit from editors with features supporting more than plain text. And a point about unit type specification irrelevant to the file format.
Not very convincing.
1) if you need an IDE to write comfortably XML that's a sign that it isn't a good format for men.
2) as for computers, it isn't a very good format either: the schema's syntax comes to mind..
I am a database guy. Typically I'm against XML (especially in a database) however, I have a scenario where there is a test system and there are some standard bits of information (test description, stats, etc.) that all the tests have but they all come out in a different structure meaning: I have 4500 queries that test different aspects of our data-set and they all come out with different columns.
They have different columns because it deals with about 600 different tables and the output is what is relevant to the test. I have decided that in this instance, I want to capture all of the results in a single table so that they are centralized. XML solves this issue for me. I can grab the results in XML, and insert them into a centralized table where they can be reviewed later.
TL;DR XML can solve some data structure issues where you don't always know the final output until it shows up.
14 comments
[ 2.5 ms ] story [ 43.3 ms ] threadIf 99% of XML uses make a bad name for the rest of them, the problem is with XML. "XML" is not a spec - it's a culture, and the culture is rotten, and Linux calls it out. Even if there's the occasional good use of XML, it pales among all the other horrible uses -- and every rare good use of XML is not actually better than the alternatives.
Author blames Linus for using "m" to signify "meter" instead of "miles" as being incomplete. Well, every nontrivial important measure is in MKS, in which "m" is properly distinguished from "mm", "cm", "km". (And by the way, did the post mean nautical miles, or ground miles?)
ISO 8601 does specify a standard for duration. I've only ever seen it used in vCalendar entries - I've seen DD:HH:MM:SS everywhere else. So while it is an ISO standard, much like OOXML, almost no one actually uses it - in which case I wouldn't be hard on Linus for not using it.
> Also I'm very confused why temperatures are given in Coulomb.
Me too, but it's still more sane than giving them in Farad like some people do :)
That should be a subject of education. I never new about that ISO 8601 until I seen an xkcd caricature, whereas I should have known only that standard notation in my education!
Property files go a long way to help differentiate it. XML has invaded almost all aspects of Java programming, but it seems things are getting better with Java EE 6 and the web services annotations for example, but application servers and framework authors need to stop cramming XML this and XML that for configuration files.
This needs to stop.
"XML shall be straightforwardly usable over the Internet."
The bewildering number of XML specifications to simply use an XML file makes it daunting for anyone to learn to use XML "properly". The XML standard today is hardly anything but "straightforward".
Additionally, it is not a particularly efficient format for machines nor for humans to use. Saying that a good editor can solve everything is a very flippant way of addressing the common challenges with editing maze-like XML documents.
Perhaps Linus didn't elaborate on the context of his criticism for the XML format, but it resonated with a lot of programmers not because of his popularity but they had faced similar painful situations before.
[1]: http://www.w3.org/TR/REC-xml/
Subsurface XML's are, to me at least, reasonable. Does it follow a spec? No. Can I, a human, look at it and say that 'm' stands for meters? Sure, the context is "humans diving" so 'm' can stand for miles. Being a human means I can process contextualized information.
Man, I really hate XML and have some dislike for its defenders.
What I'm trying to say is: is this just making a general and well-worn case for XML or is there a point relevant to Subsurface? I'm sure I could find a shallow remark made by this author and write 1000 words of qualification around that too. Right now, all I see is someone responding to a statement from a big name for attention.
Is there a argument hidden in there about XML's relative ease to work with compared to other formats, either programatically or as a user? Any points on if XML is the right or wrong choice of tool for subsurface?
The closest thing I see is a throwaway comment about an instance where CSV files also benefit from editors with features supporting more than plain text. And a point about unit type specification irrelevant to the file format.
Does XML make a file understandable by a developer in superior ways to other formats? Not especially.
Does the use of XML make error recovery from a partially borked file possible? Not really.
What problem is actually solved by XML (that other formats don't also "solve" ... and better?)
They have different columns because it deals with about 600 different tables and the output is what is relevant to the test. I have decided that in this instance, I want to capture all of the results in a single table so that they are centralized. XML solves this issue for me. I can grab the results in XML, and insert them into a centralized table where they can be reviewed later.
TL;DR XML can solve some data structure issues where you don't always know the final output until it shows up.