Re: [xml-dev] XML's greatest cultural advantage over JSON

["Simon St.Laurent" <simonstl@simonstl.com>]

Thanks - this proves my point.  (Though I think this is from a different 
David.)

Please go explore more of the world before blasting it as foreign 
religion.  The JSON folks have more and better experience than you're 
willing to acknowledge exists.  It may not fit what you want to do, but 
that's not all there is to do.

They aren't always right, but this is depressing.  The only guilt is in 
watching the spectacle.

Thanks,
Simon

On 4/28/13 7:55 AM, David Lee wrote:
> I totally agree you will never win over JSON advocates with anything else.   Or probably the reverse.
> It is a lost cause.  It's like converting a member of <religion_a> to <religion_b> But that doesn't mean talking about it is a lost cause.
> There are still the next generation (either by age or change in vocation or specialty) who have an open mind.  Well that sounds biased,  lets say
> a mind not yet decided and closed to introspection.
>
> I would *never* use JSON voluntarily unless I had to send data to a JavaScript program.   Even then, if I could avoid it I would,
> but if you read below any other format wont fix JavaScript so WTF.
>
> But it's not because I don't know JSON ... quite the opposite.  At $EMPLOYEER  I am responsible for a majority of the JSON
> implementations.   And almost daily run into yet another insanity.
>
> Todays (literally TODAY's) insanity.	
> <JSON RANT IGNORE IF YOU DONT WANT TO HEAR IT>
>
> JSON is supposed to be a good model to map Computer Language data objects ... and transfer them to other systems ...
> For a while I actually bought that line ...  Maps / Arrays / Strings / Numbers ... very basic and largely ubiquitous ... Simple. Clean.  Whats not to like
> if you only need those things ... and face it, those thigns are the core of most simple messages and data structures.
> Sure it doesn't do "documents" well but then neither do most (non DSG) internal  programming language models so lets try to pretend thats not a problem.
> And if your not "doing documents" its not.
>
> But not being a JavaScript Expert but rather one who has to support JSON in depth ... having read what I could of the "specs" many many times,
> I blindly missed a tiny tiny simple little thing.   In hindsight it should have hit me like a slaming door in my face but it didnt .... my blindness and assumptions prejudiced me.  my fault.
> Here it is.  Numbers.   Forget Dates (JSON doesnt do them) Ok dates are hard anyway, who needs them.
> But Numbers ... MOST computer language have numbers.
> And Most of them have a distinction between integers and floats (which is both arcane and useful depending on where you sit).
> JSON indirectly defines its numbers from JavaScript.  So Far so good.   Well it so happens many perfectly normal computer languages
> have 64 bit integers ... They look and quack like numbers.   I serialized them as a JSON Number and our regression tests worked great because
> OUR JSON processor read them back as numbers.   Ha Ha.  Until the Web team read the JSON files in the browser and the numbers silently changed.
> To somewhat different numbers.  No errors or anything  just a different number.  They passed it back to the server and it mismatched.  ##$!!!!
> Ok back to the "Specs" ... A side effect of JSON being based on JavaScript instead of its own spec is it inherits JavaScripts concept of a number,
> which is a 64 bit float.   With only 53 bits of integer components.  When presented with an integer with > 53 bits of integer components its pleasantly
> changed into a different number - in javascript atleast.  Your JSON compliant parser may vary.  (oh  yea there is no such thing) <DUH>
>
> OK now I know this is totally common in most languages where you try to cast <big number> -> <Smaller number> ... crash/bang/warning/error
> And I know 64 bits is HUGE ... like bigger than any computer language actually uses right ? I mean who uses anything > 16 bits <cough> 32 bits ...
> But for a Data Exchange Format ... that is NOT supposed to be tied to a particular language ... and is intended to easily and simply exchange
> data from one computer language to another ... well .. .the best I can say is I am dismayed.
> There are of course workarounds like "Dont do that you idiot" ... and RTFM and all that ... ok fair enough.
> But for a data exchange "specification" (quoted because I cant quite find the authorities specs that dont define) ...
> that happens to derive from a particular language nuances with primitive by modern (aka post 1990's) concepts of something as simple as an integer ... and that the promised interoperability is a sham,  Sorry I dont have a better word.  Altough I can think of more inflamitory ones.
> its really just "What JavaScript Does - take it or leave it". <sigh>
>
> Which by the way is just fantastic if what you are doing is serializing JavaScript objects.... So no objection there.
> But dont fool youself into thinking its anything but.
>
> Sorry ... I just won't ever use JSON Voluntarily.
>
> Now if you got this far ... and missed my *previous*  post ... and are thinking "But the Performance and Fat Free aspects are what count! They overweigh  the other tiny issues."
> Please help put your money where your mouth is and participate in this quick test.
> Results from the collective will be published later this year.
> Maybe you are right and I will then eat a crow sandwich.  In public.
>
> http://speedtest.xmlsh.org
>
> <was that enough guilt ? for $19.99 I will supply more !>
>
>
>
>
>
>
>
> ----------------------------------------
> David A. Lee
> dlee@calldei.com
> http://www.xmlsh.org
>
> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Sunday, April 28, 2013 6:33 AM
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML's greatest cultural advantage over JSON
>
> On 4/27/13 11:29 PM, w3c@drrw.info wrote:
>> Simon,
>>
>> I just blogged on this here:
>>
>> https://blogs.oracle.com/xmlorb/entry/analysis_of_json_use_cases
>
> I understand the thrill of fighting the tide, but I think you'll maybe
> win over one or two people who weren't already on your side with that one.
>
> It doesn't read like you've actually used JSON voluntarily.
>
> Good luck,
>


-- 
Simon St.Laurent
http://simonstl.com/