By Anthony Carrico
http://memebeam.org/acarrico/doc/json-talk.html
Here are the two examples from RFC4627:
"This is a JSON object:"
{"Image":
{"Width": 800,
"Height": 600,
"Title": "View from 15th Floor",
"Thumbnail":
{"Url": "http://www.example.com/image/481989943",
"Height": 125,
"Width": "100"},
"IDs": [116, 943, 234, 38793]}}
"Its Image member is an object whose Thumbnail member is an object and whose IDs member is an array of numbers."
"This is a JSON array containing two objects:"
[{"precision": "zip",
"Latitude": 37.7668,
"Longitude": -122.3959,
"Address": "",
"City": "SAN FRANCISCO",
"State": "CA",
"Zip": "94107",
"Country": "US"},
{"precision": "zip",
"Latitude": 37.371991,
"Longitude": -122.026020,
"Address": "",
"City": "SUNNYVALE",
"State": "CA",
"Zip": "94085",
"Country": "US"}]
2001 Douglas Crockford started using JavaScript object literals for data messages, calling it JSML (JavaScriptMessageLanguage), but that acronym was taken, so Chip Morningstar suggested JSON (JavaScript Object Notation).
2002 Douglas Crockford set up json.org, and he writes, "with no other promotion or proselytizing JSON has become an international stardard, displacing XML in a growing number of applications. Lots of people independently discovered that it was just what they needed."
2006 The Internet Society published Douglas Crockford's, The application/json Media Type for JavaScript Object Notation (JSON) as RFC4627.
No. JSON shares syntax with JavaScript literals, but this fact isn't important if you don't happen to be working in JavaScript. Again, JSON is compeletely language independent.
JSON parsing and serialization procedures have been written for many programming languages. You could probably write one yourself very quickly. You can use recursive descent (except for some comma/colon line noise).
JSON's model seems to map directly on to programming language concepts. Arrays are sequences, and objects are records or structures. Contrast this with XML's elements, which are a sort of hybrid--every XML element is a set of named attributes and a sequence of children.
However, remember that in many programming languages, objects have a (static or dynamic) type. In XML, element names are a very natural way to model type tags. In JSON, you have to pick some convention if you want this feature. In the first example above, the outer object is really just an "Image" tag enveloping the data. In the second, presumably the application expects exactly this particular set of data, or if it is polymorphic it must identify the type according to the particular set of member names.
There currently is no schema language associated with JSON. To quote Crockford: (source):
Re: JSON, schemas & RELAX NG
> I am interested in defining the expected structure
> of JSON objects in a way that can be programmatically
> introspected. Such definitions could be used for
> validation and for other purposes.
Early on I designed a schema notation for JSON in JSON. But on
reflection, it didn't appear to do anything that an application
shouldn't already be doing in the process of checking its inputs. So,
it having little apparent value, I didn't implement it.
I think other people have had similar experiences.
If you think there is value in schemas in JSON, go ahead and implement
it. I don't think anyone is opposed to the idea. I just don't see a
lot of value in it, except perhaps for helping people who have been
indoctrinated in XML to take their first steps toward JSON. Maybe
there is value in that.
I personally disagree. A schema language is important for documentation, if nothing else. The Relax NG schema language is one of the nicest things associated with XML. I have been adapting that model to work with JSON. Here is an experimental JSON syntax:
{"object":
{"member":
{"image":
{"object":
{"interleave":
[{"member": ["Width", {"int": true}]},
{"member": ["Height", {"int": true}]},
{"member": ["Title", {"string": true}]},
{"optional":
{"member": ["Thumbnail",
{"object":
{"interleave":
[{"member": ["Url", {"string": true}]},
{"member": ["Height", {"int": true}]},
{"member": ["Width", {"int": true}]}]}}]}},
{"member": ["IDs",
{"array":
{"one_or_more": {"int": true}}}]}]}}}}}
And here is an experimental compact syntax:
object{
member image{
object{
member Width{int{true}} &
member Height{int{true}} &
member Title{string{true}} &
member Thumbnail{
object{
member Url{string{true}} &
member Height{int{true}} &
member Width{int{true}}}}? &
member Ids{
array{one_or_more {int{true}}}}}}}
The syntactic connection to JavaScript creates the temptation to do insecure or imprecise things when working in JavaScript, such as using the eval procedure as a parser. Even Douglas Crockford's own parser, json.js, has a bug of this sort:
js> "bar".parseJSON()
typein:130: parseJSON
This code attempts to parse the text bar, which is not legal JSON. It throws an error as you would expect.
js> fee = "secret"
secret
js> "fee".parseJSON()
secret
The text fee is also not legal JSON, but instead of throwing an error, it reveals the secret! This could be a potential security loophole in an AJAX application.
This bug exists because the parser isn't really a JSON parser. It is a JavaScript evaluator "protected" by a regular expression.
Be careful when using Douglas Crockford's code, since it apparently has a nonstandard license, which includes the term "The Software shall be used for Good, not Evil." Cute, but obviously this clause makes the work proprietary. I say apparently, because he bills json.js as open source, and the code itself doesn't include a copyright or mention a license.
Instead of using a normal mailing list, JSON uses a "Yahoo Group", which (IMHO) isn't very convenient. I believe that Douglas Crockford works for Yahoo, so that is probably the reason.