"'Is the existence of JSON news?': JSON's simple values are the same as used in programming languages. JSON's structures look like conventional programming language structures. No restructuring is necessary. JSON's object is record, struct, object, dictionary, hash, or associate array. JSON's array is array, vector, sequence, or list ..."
It's not the existence that makes it worth posting. It's the why it's used.
One of the questions I was wrestling with yesterday was, "Why am I thinking of using XML as a data format when all I want to do is give users access to their data?". "Do I really need to spend excessive time developing a data standard with XML schema's . Then burden my code with machinery to manipulate it?"* "Do users really want this now?". Asking these questions I realised the approach I was taking was code-calorie rich. Too rich and the better alternative is "Fat-free" JSON. Hence the inclusion.
".. The cost of adding a feature
isn't just the time it takes
to code it. The cost also
includes the addition of an
obstacle to future expansion.
... The trick is to pick the
features that don't fight
each other."
I used to hang out on Slashdot a lot and I remember reading an interview with John Carmack back in the 90's. I can't find the references now. But the gist of it summarised in the above Carmack quote. HackerNews is what hackers find interesting. Data formats are interesting. Choose the wrong one and you may hamper yourself later on. Case in point is a new xml format that is in development. It work well. But does it need the extra 30Mb in software libs to run it? ~ http://knitml.svn.sourceforge.net/viewvc/knitml/knitml_core/...
I wonder if the readers on this site and/or those who use JSON use it because it's just there in their toolkits. Or do they purposefully choose it after asking why?
JSON is not a document markup language; it is a data structure interchange format. KnitML actually needs to be a document markup language. Therefore your example implying that XML was the wrong choice for KnitML is based on a lack of understanding about what the language's intent.
Also, you seem to imply that an "extra 30Mb in software" has something to do with the fact that it's processing XML. That is a pretty wild assumption and is simply not true. First of all, the 30Mb is in reality too large because of a Maven bug which duplicates JAR file dependencies in a ZIP archive. The true size of the app is about 15Mb (and the upcoming release will in fact be much smaller). Secondly, JiBX is the only third-party code which does XML processing. The rest is built into the JDK. So you're really only talking 7 Mb. But it's not relevant, because you are not making a clear argument.
