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

[Allan Doyle]

On Mar 15, 2007, at 12:04, Geoff Hendrey wrote:

> 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

I was a little surprised to learn that <script> circumvents the  
security model. It seems to me that relying on that behavior could be  
a bit risky from an architecture point of view.

>
> 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.

I'm not familiar with the OpenLS model and I sure won't download it  
based on the click-through agreement that's on the OGC site.

I like what's at http://wiki.geojson.org/GeoJSON_Features

(Maybe I should have used <religious-war> tags...)

	Allan

>
> -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
>
> _______________________________________________
> 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