XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] XML's greatest cultural advantage over JSON

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/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS