Talk:JSON/Archive 1

Archive 1

Archive 2

First example?

Does anyone have a perfect "first JSON object" example? —Preceding unsigned comment added by 205.174.8.4 (talk • contribs) 21:11, 2 May 2005

JSON and YAML

Can anyone compare JSON and YAML? —Preceding unsigned comment added by 205.144.62.1 (talk • contribs) 13:50, 6 September 2005

Synchronous?

How is the given example synchronous? It specifies an event handler to be called on each change of state. —Preceding unsigned comment added by 144.32.106.26 (talk • contribs) 13:33, 9 September 2005

eval()ing code sent from the server is not a good thing

To maintian a neutral POV this article needs to have the outspoken critics view that eval()ing code sent from the server is not a good thing. See http://blogs.ebusiness-apps.com/jordan/index.php/17/. I would modify this article myself, but I just found out what JSON is this morning. - Jay Buffington 16:41, 20 October 2005 (UTC)

This is an incendiary opinion article on why XML is better than JSON, not on the relative security of evaling JSON sent from a server. The assertion still stands: without cross-domain access (disabled by default), if you cannot trust the JSON coming over the XMLHttpRequest, then you can't trust the page itself, as both are guaranteed to be coming from the same source. capnmidnight 15:54, 5 December 2006 (UTC)

YAML is not a subset of JSON

YAML is not a subset, superset, anything related to JSON other than that both seek to be lighter, simpler alternatives to using XML. Don't let the fact that you can write files that are equally parsable by JSON and YAML parsers fool you. —Preceding unsigned comment added by 65.171.234.176 (talk • contribs) 21:06, 6 January 2006

I was going to comment on the exact same thing: the syntax of YAML is certainly not a superset of JSON, so saying that YAML is a superset of JSON is very confusing. Possibly, YAML is functionally a superset of JSON? In that case, we should change the formulation. --Ebruchez 13:27, 2 June 2006 (UTC)

see YAML. In a nutshell, JSON is a small subset of YAML. Any JSON document can be parsed by YAML, after striping out the block comment tags. Both YAML and JSON are based around the representation of data structures by hierarchies of maps, arrays and scalars. JSON format is basically a special use case in YAML that is convenient and vertically compact when one does not care about human legibility. In general YAML users prefer the standard YAML syntax which avoids having to enclose things in braces and quotation marks. For example both of the following are valid syntax for a YAML map. One of these is also valid syntax for JSON which is why YAML can read JSON but not vica versa. The first form is the "preferred" yaml style for most situations, though the vertical compression of the JSON-style is sometimes handy.

name:  john smith
age:     13

and

{ "name": "john smith", "age": 13 }

YAML specifies many datatypes beyond JAVASCRIPT primitives like floats, ints, and strings: for example, binary, ordermaps, timestamps, and user defined classes. Also it has anchor and references so that duplicate data need not be redundantly entered. Likewise arrays in YAML can either be like JSON which uses brackets [], quotes, and commas, or it can use the YAML indented form that avoids those enclosures. —Preceding unsigned comment added by Cems2 (talk • contribs) 11:13, 20 July 2007

Ruby on Rails NPOV?

Right now, part of the article reads:

• YAML, the data serialization language favored by the Ruby programming language...
• ...makes for quite elegant integrations between Rails and Javascript.

I was unfamiliar with YAML, and this gave me the false impression that it was a "Ruby thing". After poking around on YAML.ORG, I see that it's not Ruby specific at all. YAML.ORG's front page makes mention of "scripting languages such as Perl and Python" but Ruby is not mentioned up front (by name). Mentioning Ruby on Rails in this context doesn't look very NPOV. If there's a good NPOV reason that Ruby and RoR should be mentioned in this JSON article, please let us know. If not, I'm going to pull those references next week (unless someone does it before I do). -Gamol 05:01, 3 December 2005 (UTC)

It seems to me that you've probably misunderstood the article. As I understand it, the standard Ruby libraries fully support YAML, and furthermore that this can be said for very few if any other comparable languages. If it is true (or if it later becomes true) of some other comparable language, then the article can accordingly be modified. In the meantime, therefore, it seems to me appropriate to retain the reference, given that JSON is a subset of YAML. Peak 06:55, 3 December 2005 (UTC)

I don't think I've misunderstood the article as it is written. After doing some reading, I have a recommendation I feel quite sure about.

As I understand it, Ruby has used YAML as its "de facto serialization format .... since 1.8" (YAML wiki ref). Now since YAML is (by lucky coincidence) is a superset of JSON, Ruby programmers can use JSON almost as if it's a native data type. This is very cool and--I agree--worthy of mention. The problem I see now is that the article introduces and defines YAML in terms of its relationship to Ruby. I still feel that this is misleading. YAML.ORG and Wikipedia's own YAML article don't do this because, although it's integrated nicely with Ruby, YAML is not Ruby specific.

I think it's more appropriate to define YAML in terms of its relationship to JSON. Then, mention the Ruby integration afterwards. Give this a read:

YAML, another data serialization and lightweight markup language, is a superset of JSON. YAML can be thought of as JSON with a handful of extended data types. JSON is much easier to parse, though[1]. Although coincidental, this relationship means that YAML tools can process JSON data. The Ruby language, which uses YAML as its built-in serialization format, can handle JSON like a native data type.

Now I'm not a Ruby programmer (yet), so I'm not sure my use of "native data type" is wholly appropriate but I think the paragraph should be changed so that it reads something like the above text.-Gamol 13:50, 3 December 2005 (UTC)

Perhaps you missed a small change I made in the intro, that introduces YAML as an extension of JSON. Anyway, your basic proposal is fine, but perhaps the wording would benefit from a bit more research. In the meantime, please consider this:

Some of the limitations of JSON are addressed by YAML, which is a superset of JSON. Although JSON is significantly simpler than YAML[1], YAML is still considered lightweight. The Ruby programming language uses YAML as its de facto serialization format and can therefore handle JSON.

By the way, I am not sure that YAML is usefully considered a markup language (They don't call it 'YAML ain't Markup Language' for nothing :-) Perhaps the articles on JSON and YAML can be strengthened by explaining their superiority as "data interchange" languages compared to vanilla XML.Peak 19:26, 3 December 2005 (UTC)

P.S. I just noticed that the article List of lightweight markup languages states categorically that JSON and YAML are not markup languages. Perhaps the point of confusion is the difference between being a ML versus being used as a ML? Peak 20:39, 3 December 2005 (UTC)

Hmm, I got that "lightweight markup language" part from the (apparently) underdeveloped YAML article itself. Knowing this, I would have written "lightweight serialization syntax". I liked your last paragraph much better than the one in the article so I made that change. -Gamol 11:01, 6 December 2005 (UTC)

I would like to see the YAML/JSON relationship fleshed out in the future. Right now, readers can see that YAML is a superset of JSON and reasonably conclude that YAML was based on JSON (when in fact, the superset/subset relationship is coincidental). Also, some readers might miss the implications of this. I think it would be helpful to spell out that, because of this relationship, any YAML parser can be used to deal with JSON data structures (because strictly speaking, they're JSON parsers too). -Gamol 11:01, 6 December 2005 (UTC)

No-one has remedied any of the problems with this section. As it is now (Sept 2006), it is poorly written. In fact it almost makes no sense, because it says "The Ruby programming language uses YAML as its de facto serialization format and can therefore handle JSON with particular ease" without ever mentioning the subset/superset relationship. Nothing in the section, or elsewhere in the article, bears out the "therefore" part of that sentence.

Security risk?

As kind of implied in the comment above, doesn't eval()ing code from another server require that you have absolute trust in the "data" source? I mean, in the example code on the article, anyone who can insert content into http://example.net/this/is/a/fake/url/ can execute whatever JavaScript code they want, in the context of the website "receiving" the data.

Obviously, it's not impossible to trust the "data" source (and I saw somewhere that XMLHttpRequest() can only retrieve from the same server), but surely the importance of doing so should be mentionned very explicitly in the article. Or is there something I'm missing? - IMSoP 13:00, 4 November 2005 (UTC)

XMLHttpRequests are bound by the Same origin policy. But it is possible to load JSON objects using a proxy or other techniques. Now about evaling potentially dangerous code: I agree that this should get some mention. Perhaps the gist of the additional material could read:

If you're loading data from your server there shouldn't be a problem (and if there is a problem, you've got a serious issue that has nothing to do with JSON). But if you're using any of the techniques that can load data from a server you don't have control over, you are putting your trust in whoever's running that server. If, for some reason, you are loading JSON from a source you don't trust (WHY ARE YOU DOING THAT!?), you should validate the code before evaling it (by checking for function calls that shouldn't be there, etc).

...or something along those lines. - Gamol 08:17, 24 November 2005 (UTC)

OK, I've gone ahead and added a subsection on this. Incidentally, I came up with a reason this might end up happening - with people talking of JSON as an alternative to XML, imagine something like RSS being translated into JSON; then imagine people making "JSON/RSS" readers that blithely eval() code from Joe Random Hacker's blog... I think this is a rather important limitation of JSON as compared to a "proper" data format like XML (or rather, a flaw in its widely used parser and selling point, the eval() function). - IMSoP 20:49, 29 November 2005 (UTC)

> imagine something like RSS being translated into JSON

Actually, I forgot about JavaScript feeds. People are doing this sort of thing and they're doing it in a way that doesn't let them validate the foreign data. At least if they were using JSON, they could vet the info and make JavaScript feeds safer. I'm sure there's some your-site-is-in-danger security warning about these but I haven't heard of any serious exploits via the practice. Here's some JS feed sites: The Scotsman, RSS-to-JavaScript, some Google results.-Gamol 04:04, 7 December 2005 (UTC)

JSONT

I inserted a link to my article about JSONT. The combination JSON/JSONT can be seen as roughly equivalent to XML/XSLT.

JSONT

If you think it is closely related to JSON, I could write some more about JSONT.

If you don't think so, feel free to also remove the link.

Meanwhile there is also a link from json.org to JSONT.

Stefan Gössner —Preceding unsigned comment added by 80.144.145.74 (talk • contribs) 17:46, 6 February 2006

well ok, it doesn't seem to fit. —Preceding unsigned comment added by 80.144.145.74 (talk • contribs) 17:48, 6 February 2006

External link to BarracudaDrive and JSON security

I have re-introduced the external link removed by Sleepyhead81. For what reason did you remove this link? This is a good example of how to use JSON. I changed the link to the technical information page for BarracudaDrive.

I do not agree with the security considerations when using JSON in a browser: "in practice, however, security and other considerations generally preclude using eval"

This is only a problem if doing cross site scripting, which is normally not allowed anyway. A DHTML application is loaded on demand from a server and communicates with the origin server i.e. you cannot trust the DHTML application itself if you cannot trust the JSON returned form the server as it originates from the same server. How many users do "view source" and study the JavaScript code before trusting a DHTML application.

What I am trying to say is that any code loaded on demand, including a JSON parser cannot be trusted. It is for this reason no difference between using eval and using a JSON JavaScript parser when it comes to security.

—Preceding unsigned comment added by Syberguru (talk • contribs) 17:15, 11 February 2006

I removed it because I consider is a spamlink. It is an example, but there are heaps of examples. Adding one example will only attract other links which has been the case with other similar articles. --Sleepyhead 08:20, 15 February 2006 (UTC)

That is an opinion.

BarracudaDrive is designed to be an example and a showcase for what is possible with HTTP, AJAX, etc. The search is a particular good example as it shows how much faster asynchronous RPC can be made using JSON than with SOAP. BarracudaDrive is also a good platform for users that are interested in experimenting with the JSON server API. Personally, I do not think you should remove any links. What gives you the right to act as the police and censor what other readers may find useful? There is already a lot of spam in the JSON article and many statements that are not necessarily correct.

—Preceding unsigned comment added by Syberguru (talk • contribs) 16:19, 17 February 2006

History

Where is the history section? Who coined the term, etc.? 70.20.193.90 19:05, 2 July 2006 (UTC)

A month later, and I'm still trying to figure out where "JSON" came from. Who started the spec? And why doesn't this article mention him/her??? 70.20.147.17 03:33, 1 August 2006 (UTC)

I partly answer your question with a couple of sentences with info about JSON specifications and roots. Right now it's the second paragraph. --Gosub 22:23, 9 September 2006 (UTC)

Douglas Crockford might be worth mentioning as his page claims he created it. 207.126.230.225 22:59, 24 October 2006 (UTC)

Cross-site request forgery

User:69.232.196.25 wrote (on the article page, moved here):

This section is not concerned with JSON. It does not belong in this article. It is concerned with a misuse of the HTML script tag. It also recommends an incorrect solution to the problem. The correct solution is for the server to be more discriminating as to where it sends passwords and other sensitive data.

I assume the IP failed to understand the issue; perhaps it could be explained better? The attack works as follows:

1. Alice logs into her webmail, run by Bob
   1. Bob sends Alice a session cookie
2. Alice's web client uses the session cookie to retrieve her emails
   1. Bob sends Alice an AJAX page
   2. Bob's AJAX page, running in Alice's web client, sends a JSON request
   3. Bob responds to the request, sending the data to Alice
3. Edgar sends Alice an email containing a link (free porn, perhaps)
4. Alice clicks the link and goes to Edgar's web site
5. Edgar's web page contains a script tag pointing at a URL on Bob's webmail site
6. Alice's web client follows the script tag
7. Bob's webmail site validates Edgar's request (because Alice's web client sent the session cookie) and responds with JSON
8. Edgar's web page, having peeked into the JSON from Bob's webmail, has been able to read Alice's email and sends that email to Edgar.

--EdC 01:11, 17 December 2006 (UTC)

Note that:

• the person who is misusing the script tag is the attacker, so neither the web services provider nor the user can do anything about it
• Alice may know not to click links in emails; that won't help, as an alternate attack scenario is to pollute a high-traffic web site (e.g. Slashdot) and hope that some of the visitors are logged into GMail (which they will be)
• "The correct solution is for the server to be more discriminating as to where it sends passwords and other sensitive data" — how? The server is sending data to the victim's web client, which has requested that data with a currently valid session cookie.

--EdC 01:26, 17 December 2006 (UTC)

JSON vs XML

"XML is however a markup language and is thus significantly more complex than JSON, which is specifically designed as a data interchange format, not a markup language"

I don't follow this reasoning. Markup languages are not more complicated by definition over data interchange formats. The two are also not mutually exclusive -- XML is a markup language designed for data interchange.

As to complexity:

  {
      "firstName": "John",
      "lastName": "Smith",
      "address": {
          "city": "New York, NY",
          "zipCode": 10021,
          "streetAddress": "21 2nd Street"
      },
      "phoneNumbers": [
          "212 732-1234",
          "646 123-4567"
      ]
  }

vs.

 <person>
    <firstName>John</firstName>
    <lastName>Smith</lastName>
    <address>
       <city>New York, NY</city>
       <zipCode>10021</zipCode>
       <streetAddress>21 2nd Street</streetAddress>
    </address>
    <phoneNumbers>
       <phoneNumber>212 732-1234</phoneNumber>
       <phoneNumber>212 732-1234</phoneNumber>
    </phoneNumbers>
 </person>

I'll grant you that XML is more verbose, but 'significantly more complex'? 209.131.211.194 18:52, 20 December 2006 (UTC)

To enhance your statement, XML is for eXtensible Markup Language. --80.217.189.168 19:14, 26 January 2007 (UTC)

• For the human eye the complexity between both languages isn't much different, specially in your example which isn't really a valid XML document and only covers extremely basic XML features. On the other hand, if you want to write a parser then JSON will be a lot easier to parse than XML. I'm writing a JSON parser and the finite state machine to read a JSON document DOM-style has less than 40 states, being the bulk for parsing the number value alone. do you care to know the order of magnitude of states a FSM to completely parse a XML document, with namespaces and all? Hundreds, if not thousands. --Mecanismo | Talk 13:59, 10 June 2007 (UTC)

• No need for your XML parser to support XML Namespace if you don't want to, especially when it comes to comparison with JSON. Your point still stands on the matter of doctype declarations, which are needed to be a valid parser, though. 82.66.241.96 09:33, 25 June 2007 (UTC)

• The above two code samples are not equivalent; the object structure is different. e.g. it looks like JSON code should enclose the person entity with { "person": { ... } } Comp-sci (talk) 16:14, 8 December 2009 (UTC)

JSON and AJAX isn't "compatible"

The page states that JSON and AJAX is commonly used together over AJAX and XML. AJAX means "Asynchronous JavaScript And XML".

Do I get my point across? Oh and, Ajax is commonly used to refer to the cleaning soap. --80.217.189.168 19:12, 26 January 2007 (UTC)

If the point you're trying to get across is that you're a humourless pedant, then yes, you have succeeded. The article states that JSON is an alternative to XML in AJAX; could it be any clearer? –EdC 21:34, 26 January 2007 (UTC)

EdC, please remember to stay civil. Thank you. Let me attempt to paraphrase the anon's comment. I believe what that person is saying is that you can not have "AJAX" without "XML". Therefore, using JSON in lieu of XML makes it no longer AJAX, but something totally other. Given that, the sentence is somewhat confusing. I tend to agree with the anon in this. -- ShinmaWa^(talk) 19:20, 25 March 2007 (UTC)

• I do believe that this "compatibility" debate is pontless. AJAX may be an acronym for "asynchronous JavaScript and XML" but it represents a way to develop web applications, not concrete methods. It's the same thing as claiming that you can't have a LAMP stack if you use postgresql --Mecanismo | Talk 14:12, 10 June 2007 (UTC)

JSON and Python

JSON does not 'happen to be' a subset of Python: for starters, 'true' and 'false' have capitals in Python. The claim about eval() in Python being useful for JSON should go until somebody takes the time to find all differences between JSON and valid Python. And, as said by others, eval() is unwise anyway, especially in a non-sandboxed language like Python. --Habbie 11:29, 20 February 2007 (UTC)

Why JSON?

Why programmers call it JSON? (Javascript Object Notation) JSON is an incomplete copy of ECMA-262 and not as it should be.

Stop once and for all call in it JSON, and call it as it is. Literal Javascript which is far more than JSON. Read the Javascript ECMA-262 You'll find it easier to understand than as a sole concept not as JSON.

Understand the Object Oriented Nature of Javascript and understand that ... to start ... The correct use of Javascript is Literal Javascript What is it for? Simple ... Javascript was designed with a concept of inline porgramming.

So when you understand the structure of Javascript you will understand that the correct use of Javascript is literal, and talking about JSON is an incorrect, absurd concept.

Simple diffences like

for Javascript {key:value} or {"key":value} are the same for JSON only {"key":value} is correct

for javascript var x= 0005; is correct for JSON only var x = 5;

                                             JSON !== Javascript

So is it clear? literal Javascript === Javascript

literal javascript is only another way (the correct way for web programming) to use javascript

  as it is   x  [ "y" ] = value  or   x.y=value  <- this is liteal javascript in Javascript, don't call it JSON.
  as it is  x [ "y" ] = value   or  x={Y:value} <- this is literal javascript too, not JSON

—The preceding unsigned comment was added by 216.62.70.35 (talk • contribs).

OK, I can't say I entirely understand all the points you're trying to make here, but the one phrase that stands out (both visually and intellectually) is "JSON !== Javascript". Now, presumably, you are under the impression that some people are claiming that this is not true, and that JSON is JavaScript; that's not the impression I got - the 'J' in the name stands for 'JavaScript' because that is it's origin, and as the article states: "JSON is a subset of the object literal notation of JavaScript and is commonly used with that language."

If you're trying to say "there are ways of writing data structures in JavaScript that are not JSON" then yes, absolutely; that's what "subset" means. Why this means that "talking about JSON is an incorrect, absurd concept" I honestly have no idea. If anything, it makes the term all the more necessary, because we need some way of talking about the data format without mentionning the language; if you prefer, think of the JS as meaning "JavaScript-like". - IMSoP 20:00, 25 March 2007 (UTC)

I think he is merely pointing out that it is silly to be calling "JSON" it's own data format. Object literals, the basis for JSON, were a conciously built in feature of Javascript/ECMAScript. It's like keeping data in a C Array, sending that C Array to a server, and claiming you have created a new data exchange format: all you've done is send C to a server. "JSON" is simply sending Javascript to a server. Javascript is Javascript, no matter how it is parsed. I concur with his post, it is silly to give a feature of javascript an entirely new name like this. - Gavin86 11 May 2007

JSON may be valid JavaScript, but not all JavaScript is valid JSON. If you contend that it is "silly" to give JSON a name, then how will you describe the kind of data that you are sending over the network / storing in a file / etc.? "JavaScript object notation", I hear you say? Congratulations, you have just reinvented the name. Shinobu 23:23, 13 May 2007 (UTC)

Meh. I still think it is silly. They just force the use of quotation marks. And nah, I wouldn't say JSON, I would say, "I am sending object literals". Not a huge deal, I just think it's silly Gavin 23:13, 15 May 2007 (UTC)

It doesn't really matter whether you think JSON is a good name or a bad name. This is what it is officially called, so this is what WikiPedia must document. Now, as far as JSON goes, it is important for it to have a name since it really is a separate and distinct "language", regardless of it's similarity to JavaScript. It has a distinct MIME type, a different intentended purpose, a different standardization path. And keep in mind that at this point JSON is used as a generic data format in systems that don't use a shred of JavaScript code; and also that JSON does differ from JavaScript in some other minor aspects as well, such as the numeric semantics or the permissible white space characters. So JSON, although similar to and based upon JavaScript, truely is a separate language. - Dmeranda 16:55, 16 May 2007 (UTC)

Consider an analogous situation: the XBM image format, which is a proper subset of the C language. Just because XBM is C code, using literals, doesn't mean the separate name XBM wasn't useful. The same argument can be applied with JSON and JavaScript. - Dmeranda

• Sir, you are totally clueless. JSON is not JavaScript. JSON may have arise from JavaScript but it isn't JavaScript. JSON is a very light markup language. Is JavaScript a markup language? No. Is JSON a scripting language? No. So how can they both be the same thing? They can't. --Mecanismo | Talk 14:05, 10 June 2007 (UTC)

If anyone out there wants to "invent" PSON (Perl-Style Object Notation), CShON (CSharp Object Notation), ConFUSiON (ColdFusion-style Object Notation), XSySON (XML-style Object Notation) or any other similar notation for any known or yet-to-be-invented programming, scripting or markup language ... too late, I hereby declare my inventions to the public.

The specifications are as follows: a subset of the already-made specifications for the already-made aforementioned languages, using just a proper subset of the relevant specifications to represent data structures of type: 'list', 'mapping', 'string', 'true','false','null','integer','float', and any other built-in intrinsic type of any 3GL or 4GL programming language, and any combination thereof.

I would have declared JSON and the rest of my inventions back in 1995, but I have to give recognition to Doug Crockford, since it never occurred to me that I could take credit for "inventing" something that was already available as a pattern of sensible coding practice in any given language.

Now that my inventions have been declared, I request that you wait for them to become acknowledged by mainstream reliable sources before writing Wikipedia articles about them. This exciting breakthrough, although destined to change the course of history, still must be treated like any other article topic. Thank you. dr.ef.tymac 18:54, 5 October 2007 (UTC)