Using JSON instead of XML for OGC documents

[Christopher Schmidt]

This discussion is more appropriate to webmap-dev than anythign else:
moving it to only be on that list.

On Fri, Nov 17, 2006 at 02:03:46PM -0600, Adam Hill wrote:
> Cameron wrote:
> >* In Web Browsers, XML support is patchy.
> 
> I am curious. What browsers don't have basic read/write XML support? Opera?
> Safari?
> 
> Or is there some missing features that make it just a PITA?

I think one of the largest problems is that browsers all implement
things just differently enough to cause them to not work the same
cross-browserly. 

I do know that the lack of xpath support in Safari has been a PITA in
the past, but I have a feeling that more recent Safari versions to
include an XSLT library. I don't know what that means for xpath support.
("more recent" == Safari 2.0+, OS X Tiger.) 

I do know that in general, migrating from an XML-based transport to a
JSON based transport (when working in Javascript) helped our performance
tremendously in one application. 

I don't know much more about it.

Essentially, when working in Javascript, JSON, especially loaded via a
callback in a <script> tag, is the way to go. This should not surprise
anyone, since the JS in JSON is "Javascript". Data created in this
manner is treated in the exact same way as if you create data via:

 var something = { 'a':
   {'hash':['or','list'], 'which':'works'},
   'quite':'quickly',
   'in':'javascript'};

You are speaking the native language of Javascript when you speak in
JSON. There is little overhead, because the format is extremely simple. 
However, the cost is that some of the flexibility of XML is lost: it is,
essentially, a dictionary/hash/associative array concept. Being able to
pull all the 'item' tags out of two different XML formats like:

<rss>
  <item />
</rss>  

<atom>
  <item />
</atom>

is possible using DOM, and probably some xpath foo. But in JSON, the
only way to do such a thing would be to iterate over the object,
checking if any of its members  had an 'item' property. In Python, that
would be something like:

  for key in hash:
    if hash[key].has_key("item"):
    	
In Javascript, it would be similar.

So, there are certainly cases where JSON might not be the right answer.
However, I'm not convinced that XML parsing in the browser is going to
solve that problem anyway: typically, in-browser XML implementations
tend to be slow enough that using XPath implementations is a line that's
dangerous to cross. DOM implementations tend to be fast enough, since
the browser has to perform lots of DOM manipulation in general -- but
getting content out of the DOM suffers the same "You have to know the
structure" limitations that JSON does.

XML is not the perfect fit for everything. Neither is JSON. Providing an
option for JSON -- especially with callback support -- where it is
appropriate might be a useful path to go down. In some cases, this might
be possible by simply adding support for a new format parameter, as in
WFS implementations. In some cases, it might mean deciding to stick to a
particular framework, so that my collection of geometries in a GML file
is always going to be called 'featureCollection' (I'm not sure if this
is restricted at the moment in GML).

I know that for those of us working in the Javascript world, with the
current lack of consistent cross-browser XML APIs, working with XML can
just be a pain. The feature you want may be implemented, but in many
different APIs. (Take a look at the standard XMLHttpRequest wrapper that
everyone has to use:
http://developer.apple.com/internet/webcontent/xmlhttpreq.html -- note
that it has support not just for IE, but *two* branches of support for
IE, plus the one standards-compliant interface.)  The feature you want
may be implemented, but too slow to be useful. Or, the feature you want
may not be implemented at all.

JSON is good for web developers, and it may be good for other developers
as well. You know that your transport format is pretty easy to implement
when someone has *implemented it in LotusScript*. 

Regards,
-- 
Christopher Schmidt
MetaCarta