[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] The JSON Data Interchange Format (ECMA standard, October 2013)
- From: Hermann Stamm-Wilbrandt <STAMMW@de.ibm.com>
- To: David Lee <dlee@calldei.com>
- Date: Fri, 18 Oct 2013 08:47:20 +0200
David,
I fully understand that you do not like JSON, and why.
But for me that is not the point, the point is whether you want support
integration between XML and JSON systems or not.
Most of our customers do not start at 0 and have to integrate with other
partners. These may use XML or JSON. That is the reason why DataPower
provides support for XML, JSON as well as Non-XML processing. Its and
integration appliance.
A standard Non-XML use case in the past was to provide a SOAP facade on a
Cobol copybook Non-XML mainframe system. With being able to process JSON
natively with JSONiq (and by conversion to JSONX before) that mainframe
system can be exposed via JSON as well. I don't see a reason why not
providing our customers with that flexibility -- its their (or their
partners) decision what to use.
Finally, since JSON is reality, why not use the power of XQuery on
processing it by JSONiq?
Mit besten Gruessen / Best wishes,
Hermann Stamm-Wilbrandt
Level 3 support for XML Compiler team and Fixpack team lead
WebSphere DataPower SOA Appliances
https://www.ibm.com/developerworks/mydeveloperworks/blogs/HermannSW/
https://twitter.com/HermannSW/ http://www.stamm-wilbrandt.de/ce/
----------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
From: David Lee <dlee@calldei.com>
To: Michael Kay <mike@saxonica.com>,
Cc: "Costello, Roger L." <costello@mitre.org>, "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Date: 10/17/2013 04:17 PM
Subject: RE: [xml-dev] The JSON Data Interchange Format (ECMA standard, October 2013)
------------ Micheal
My reading is that the statement "JSON is based on a subset of ECMAScript "
is a statement about the history and origins of the spec, and has no
normative effect.
But perhaps this has caused confusion in the past and this is why the new
ECMA 404 has a clarifying paragraph on the subject.
Michael Kay
Saxonica
-----------------------
Suppose I interpret it like you do (I dont but thats fine, its unclear).
What I read exactly is
" JSON is agnostic about numbers. In any programming language, there can be
a variety of number types of
various capacities and complements, fixed or floating, binary or decimal.
That can make interchange between
different programming languages difficult. JSON instead offers only the
representation of numbers that
humans use: a sequence of digits. All programming languages know how to
make sense of digit sequences
even if they disagree on internal representations. That is enough to allow
interchange."
I very simply, and strongly, disagree that the first sentences imply the
last.
In fact I say they explicitly prove otherwise. That simply avoiding the
issue of representation
doesn't magically make it enough to "allow interchange".
Quite the opposite - by ignoring implementation and not saying anything
about it ...
any implementation can claim "JSON" compliance and not be able to
interchange data with other implementations.
For example I dont happen to know of any "JSON" processors that can
*actually* handle integers > 53 bits.
or have any defined way of interchanging such numbers. Maybe some do, but
if I want to have my app "allow interchange" with JSON ... the specs are
not helping me.
And yes XML has similar problems but at least the specs attempt to address
the issue instead of pretending it magically vanishes by ignoring it.
Thats my last rant ... I swear :)
-David
-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 812-482-5224
Cell: +1 812-630-7622
www.marklogic.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]