I definitely never saw any issues with all those XML based standards like SOAP or XSLT.
And it shouldn't even be used for data transfer: it's a markup language, for Pete's sake!
XML could never be used for data transfer. That is being done by the protocol. That would be, in most of the XML cases: HTTP(S).
GET http://en.wikipedia.org/wiki/Rolling_Stones/wp:discography/w... GET http://store.steamcommunity.com/profile/myprofile/games.xml/...
Wow! That's a beauty! And that's only because XML is BOTH a document and a data structure. It has two personalities, but only one identity. And it is not schizophrenic about it. It's always clear.
> A lot of that is because XML is objectively insane
I don't find "everything is a node" to be insane. It's like "Everything is a file" followed through up to the atomic value.
/net/host/volume/directory/file.xml/document-node/some/other/node/attribute
or
/net/host/volume/directory/file.xml//all-nodes[@where-this-attributes-value="foobar"]
Looks like a perfect match for both command line as well as RESTful access.
> monumentally over-specified
The XML spec, while having a healthy size, is not overly big: https://www.w3.org/TR/xml/
Do not confuse the additional specs like XSL, XPath and XQuery as the "XML" spec. These are your toolbox. And their volume is in no way bigger than any of the frameworks, programmers use. Also XSD is not really part of the XML spec. You don't need it in many cases.
It's a meta language, that consists of a simple convention: Elements and Attributes. You name them what you want and get a document, that, at the same time is a queriable datastructure. But I've said that already...
> RFC processes don't always keep things from having compatibility issues. XML based standards like SOAP or XSLT had many issues.
It would make the internet seem much less passive aggressive. Sarcasm is often just a thin, bitter encoding over simple statements.
Edit: obviously this isn't the case, since people have actually parsed it, yet it's a non-trivial thing to do and I have yet to see a solution that isn't horribly specific or a solution that ignores something that might be problematic in non-standard solutions (of which there are a million because of the difficulty involved). A huge amount of domain specificity doesn't help either.
Completely disagree. Gruber and Crockford are remembered as the people who came up with these really good formats, much better than the overdesigned alternatives.
Here is the lesson:
1. We need something simpler, so I will make a simple solution to this problem 2. Simple should also mean no strict spec, support for versioning or any of those engineer things. All that engineer shit is boring and I can tell myself this laziness is "staying simple" 3. OH SHIT, I was totally right about #1 so this got popular and having been designed as just a toy is causing a lot of problems for a massive number of people ... now my incompetence regarding #2 is on display and there is nothing I can do about it
I'm not saying "Thou shalt always add bureaucracy to your toy projects", but look at what happened and think about how Gruber and Crawford will be remembered, partly if not mostly, for being "the asshole who screwed up X". If you go the other way programmers will think "damn I hate these RFCs, these suits are messing up the beautiful vision of Saint [your name here]".