I wrote a JSON compiler and decompiler in October . After running a bunch of tests against other JSON people, I was pleased that it worked and moved on. I mainly focus on the compiler because it is usually the hard part, trying to understand all the variables that people can throw at you. JSON, as announced, is pretty easy to work with (although not as easy, imho, as it could be). Never mind.
Now we have a format that is starting to gain traction, JSONification of the news flow displayed by River2 . A bunch of Javascript developers work on visualizing this data, some of which are now more enjoyable than the one I use, but none of them are functioning enough for me to switch to.
But the problem is with JSON.
Each group of news bits is organized as a collection of scalar data, such as the name of the feed, the URL when the last channel was read, etc. Then there is one or more news. If there is one item, I just include a structure called item. If there is more than one, I include a list of structures. The list is called an element. I realized that this is a convention for repeating elements in JSON.
http://scripting.com/images/2010/12/17/jsonShot.gif
There are two "updatedFeed" elements in the above screenshot. The first has only one element, the second has more than one.
This creates problems for people in some languages, because (apparently) it is difficult for them to cope with the object without knowing its type in advance. Therefore, they say that the solution is simple, always make it a list. Simple for them, but ... :-)
But it is not so easy on my part. Because I am using a universal JSON serializer, and it will have no way of knowing that "item" should always be a list. If only...
One way to handle this (which I don’t like and will not do) is to make the whole list.
I'm just wondering what other JSON production environments do in such situations.