JSON Propositions

Proposition I


Strings may use single quotes.
A single quoted string is the same as a double quoted string except that double quotes are not escaped and single quotes are escaped. i.e.
"He said \"How's the weather\"" == 'He said "How\'s the weather"'

Adding this feature to JSON would avoid confusion since single quotes are supported in JavaScript. The extra functionality for current JSON parsers to support single quoted strings should be minimal if it is not already supported.

Proposition II


The double quotes around the name of an object pair are optional.
{"JSON":"In JSON the name of an object pair must always use double quotes"}

{JSON:"This is invalid JSON but maybe one day it will be valid"}

{'JSON':'If proposition I is adopted this will be valid'}

{'NotValid':This is not valid because only the name of an object pair may omit the quotes, not the value}

The quotes around the name of an object pair are not needed by the parser since the name will always occur inside an object after the initial open brace or a top level comma and end at the colon. However depending on the implementation, a new token will most likely be needed to recognize a string without quotes.


Also, like Proposition I, JavaScript supports this feature and adding it to JSON would help avoid confusion.

Proposition III


A new syntax to represent a table.
One way to represent a table in JSON is to use an array of common objects. i.e.
[
{"FirstName":"Jim"   ,"LastName":"White" ,"Occupation":"Banker" ,"Age":28},
{"FirstName":"Lisa"  ,"LastName":"Miller","Occupation":"Cashier","Age":42},
{"FirstName":"Bob"   ,"LastName":"Jones" ,"Occupation":"Manager","Age":35},
{"FirstName":"Ashley","LastName":"Brown" ,"Occupation":"Teacher","Age":32}
]
The drawback of this is that every object must duplicate the same names for every row. A new syntax could look like:
<
FirstName,LastName,Occupation,Age:
"Jim"    ,"White" ,"Banker"  ,28 :
"Lisa"   ,"Miller","Cashier" ,42 :
"Bob"    ,"Jones" ,"Manager" ,35 :
"Ashley" ,"Brown" ,"Teacher" ,32
>

The new syntax looks much like a csv (comma separated values) file with a header. The colons act as the object delimiter and the commas act as the value delimiter.


Proposition III breaks JSON's compatibility with JavaScript. This means that running the eval function on a JSON object will not always work.


Note that this new syntax does not necessarily reduce the amount of characters needed to represent a table because the same concept can be implemented in JSON by representing the data in a two-dimensional array and adding an extra object for the table header:

{"FirstName":0,"LastName":1,"Occupation":2,"Age":3}
[
["Jim"    ,"White" ,"Banker"  ,28 ],
["Lisa"   ,"Miller","Cashier" ,42 ],
["Bob"    ,"Jones" ,"Manager" ,35 ],
["Ashley" ,"Brown" ,"Teacher" ,32]
]

This representation reduces the size but makes access clumsy. If the header object was called header, and the data array was called data, accessing the string "Lisa" would be data[1][header.FirstName]. If the data is represented as an array of objects then accessing the same string is simply data[1].FirstName. The new syntax allows the data to still be an array of objects but reduces the characters needed to accomplish this.

Disadvantages of adopting propositions


  1. Proposition I and II means that current programs and libraries that support JSON may need to modify their current JSON libraries.
  2. Proposition III breaks JSON's compatibility with JavaScript. This means that running the eval function on a JSON object will not work if the new syntax for creating a set of common objects is present.

Advantages of adopting propositions


  1. Proposition I and II make JSON more similar to JavaScript which helps avoid confusion.
  2. Proposition III will create a uniform and succinct way of representing a common set of objects.

Questions/Comments


Any suggestions are welcome. If you would like this page to include any additional information on these propositions please email me at marler8997@vandals.uidaho.edu