> > > Here is a example JSON:
> > >
> > > var json = {
> > > fields:
> > > [
> > > {prompt1: "Login Name"},
> > > {prompt2: "Real Name"},
> > > {prompt3: "Location"},
> > > {prompt4: "Password"},
> > > {prompt5: "Security Group"},
> > > {prompt6: "File Area"}
> > > ]
> > > };
> > That's not valid JSON. You need double quotes on all the
> > property names.
> >
> > Obviously it doesn't make any difference if you are just
> > eval'ing it (it is valid JavaScript), but if anyone uses it with
> > a real JSON parser it will fail.
> Ok, so what you are saying that I can make it work fine for
> my own I/O handling, but to be 100% correct across the board,
> the BCP (best current practice) is I should always have my
> JSON generation code doube quote all JSON properties and I
> will not have any compatibility issue? or shouldn't?
>
> Now, must it be double quote and/or single quotes? Does it matter?
It must be double quotes. It's not a question of best current practice, it's
a question of whether it's JSON or not. No double quotes = not JSON.
> I think single quote is often used for WEB work because many
> back end languages only support double quotes for strings so
> its easy to code it. So I have been using single quotes up
> to this point and double quote it where it is specifically required.
That's totally reasonable, and at least 90% of the "JSON" data in the world
is probably consumed by non-strict JavaScript parsers, most often a simple
eval() which will accept any valid JavaScript code whether it is JSON or
not. But, to make it through any strict JSON parser the double quotes are
required.
Here is a JSON parser and some more information about this requirement:
http://simonwillison.net/2006/Oct/11/json/
-Mike
