[GeoJSON] <religious-war>size matters</religious-war>

[Geoff Hendrey]

And I am one who believes that JSON has lots of value. Huge value! I
just don't believe its value is in compactness.

I believe the value of JSON is one of necessity. To explain further:

The XMLHttpRequest is hobbled by the domain-of-origin policy. That means
that if I host maphost.com, which hosts a javascript API for draggable
maps, an application from mapuser.com cannot access my draggable map.
The security policy of the browser won't allow it.

This forces mapuser.com to install a proxy. While this is a viable
approach, it introduces complexity to the customer, mapuser.com.

The emerging approach for working around this is based on accessing the
maphost.com javascript via a <script> tag. Google JSONP (yes, that's a
"P") for more, or this article http://www.xml.com/lpt/a/1636

The bottom line is, the ONLY way to allow asynchronous browser based
clients to access a javascript from maphost.com, is via the <script>
tag. This means that the data you respond with has to be a JSON object
that calls itself into the application via a callback function invoked
from inside the script returned from the web service. Good, bad, or ugly
doesn't matter. It's the only way avoid the domain-of-origin issues.

SO the challenge I see is how to *not* throw away all the work that has
been done to create information models for OGC web services like OpenLS.
How do we take the information models, and use them in the context of
JSON web services.

-geoff

-----Original Message-----
From: geojson-bounces at lists.geojson.org
[mailto:geojson-bounces at lists.geojson.org] On Behalf Of Allan Doyle
Sent: Thursday, March 15, 2007 8:48 AM
To: geojson at lists.geojson.org
Subject: Re: [GeoJSON] <religious-war>size matters</religious-war>

You point out an interesting perspective, and it's good to know about
these things.

However, perhaps we should assume that the GeoJSON community (of 3-4
people but growing astronomically as we speak) is already convinced that
a JSON implementation of something Geo is a worthwhile experiment. So
I'm not sure this qualifies as a religious war.

Some of us might dislike XML as a transport for reasons of our own...  
either entirely (religiously) or under specific circumstances
(pragmatically) or both.

	Allan

On Mar 15, 2007, at 11:28, Geoff Hendrey wrote:

> Here is some interesting background/debunking on the myth of JSON 
> compactness vs. XML verbosity.
> This is an excerpt from an email I sent to a colleague early last
> year:
> ======================================================================
> =========
>
> I went to the json "see for yourself" page: http://www.json.org/ 
> example.html to compare the Json equivalent of XML.
>
> I copied each of the examples into notepad and wrote down the size- on

> disk:
>
> json size (bytes)           XML size (bytes)          (json size)/ 
> (XML size)
> ===================================================
> 604                             630                               95%
> 252                             221                              114%
> 630                             656                              96%
> 3554                        10708                              33%
> 898                            1150                             78%
>
> AVG (json size)/(XML size)
> =====================
> 83.2%
>
>
> Based on an average size compaction to 83.2% of the XML size. Also, if

> you look at the 4th example they give (line 4 of the table above), 
> they did a Json version of web.xml. Now web.xml is a notoriously bad 
> XML design. It basically doesn't use ANY attributes, so you get pretty

> nasty tag bloat. So if we drop the 4th comparison, as being kinda 
> silly, we get an average compaction to 95.4% of the original size. Is 
> saving 4.5% really a big advantage?
>
> I also saw several statements on the json web page that I would put in

> the "wacky" bin. This may just be personal preference, but I found the

> XML documents much easier to read than their json equivalents. The 
> Json looks, to me, like "code", kinda like a snippet of PERL or 
> something.
>
> <geeky>
> Anyway, it seems clear that being able to easily marshal an object 
> representation of your data makes it much easier to develop software 
> in any programming language. But it seems to me that json is munging 
> this idea up with the wire format, which to me are orthogonal 
> concerns.
> </geeky>
>
> Geoff Hendrey
>
> Software Architect
> deCarta
> Four North Second Street, Suite 950
> San Jose, CA  95113
> office 408.625.3522
> www.decarta.com
>
>
>
>
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

--
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org



_______________________________________________
geojson mailing list
geojson at lists.geojson.org
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org