Following up on the good argument for XML thread, JSON is simpler and more space efficient, and seems to be catching on as a data interchange format!
Casey Hawthorne
JSON (JavaScript Object Notation) is a lightweight data-interchange
format. It is easy for humans to read and write. It is easy for
machines to parse and generate. It is based on a subset of the
JavaScript Programming Language, Standard ECMA-262 3rd Edition -
December 1999. JSON is a text format that is completely language
independent but uses conventions that are familiar to programmers of
the C-family of languages, including C, C++, C#, Java, JavaScript,
Perl, Python, and many others. These properties make JSON an ideal
data-interchange language.
JSON is built on two structures:
* A collection of name/value pairs. In various languages, this is
realized as an object, record, struct, dictionary, hash table, keyed
list, or associative array.
* An ordered list of values. In most languages, this is realized
as an array, vector, list, or sequence.
These are universal data structures. Virtually all modern programming
languages support them in one form or another. It makes sense that a
data format that is interchangable with programming languages also be
based on these structures.
-------------------------------------------------------------------------------------
I wonder what the trade-offs are between JSON, XML, and other data
interchange formats.
--
Regards,
Casey
Ben Finney
> I wonder what the trade-offs are between JSON, XML, and other data
> interchange formats.
I've found many programmers using YAML <URL:http://www.yaml.org/> as
having the same advantages of JSON, with broad support in language
libraries, while being even closer to human-readable representation of
structure.
--
\ “A free press is one where it's okay to state the conclusion |
`\ you're led to by the evidence.” —Bill Moyers |
_o__) |
Ben Finney
Casey Hawthorne
On Fri, 20 Nov 2009 10:13:26 +1100, Ben Finney
<bignose+h...@benfinney.id.au> wrote:
>Casey Hawthorne <caseyhHA...@istar.ca> writes:
>
>> I wonder what the trade-offs are between JSON, XML, and other data
>> interchange formats.
>
>I've found many programmers using YAML <URL:http://www.yaml.org/> as
>having the same advantages of JSON, with broad support in language
>libraries, while being even closer to human-readable representation of
>structure.
--
Regards,
Casey
Ben Finney
> Casey Hawthorne <caseyhHA...@istar.ca> writes:
>
> > I wonder what the trade-offs are between JSON, XML, and other data
> > interchange formats.
>
> I've found many programmers using YAML <URL:http://www.yaml.org/>
The specification for YAML acknowledges prior art
<URL:http://www.yaml.org/spec/1.2/spec.html#id2708710> and even
discusses comparisons with JSON and XML
<URL:http://www.yaml.org/spec/1.2/spec.html#id2759572>
<URL:http://www.yaml.org/spec/1.2/spec.html#id2759732>.
--
\ “Value your freedom or you will lose it, teaches history. |
`\ “Don't bother us with politics,” respond those who don't want |
_o__) to learn.” —Richard Stallman, 2002 |
Ben Finney
rpost
>I wonder what the trade-offs are between JSON, XML, and other data
>interchange formats.
Clearly, JSON's syntax is simpler than XML's. For mere compactness,
something binary like Google Protocol Buffers is better.
XML has the advantage of coming with popular additional standards
for data manipulation and validation: XPath, XQuery, XML Schema, etc.
>--
>Regards,
>Casey
--
Reinier
Clifford Heath
> Casey Hawthorne <caseyhHA...@istar.ca> writes:
>> I wonder what the trade-offs are between JSON, XML, and other data
>> interchange formats.
> I've found many programmers using YAML <URL:http://www.yaml.org/>
I've used all three, and still find them all wanting.
None supports binary data well. JSON doesn't support
back-references (for use in marshalling object graphs
with recurrences), and at least the Ruby implementation
of YAML has catastrophic bugs in its recurrence handling,
where it declares false back-referecces.
YAML is fragile to white-space manipulation, for example
when sent as an email attachment.
ASN.1 encodings are robust, but not human-readable.
Clifford Heath.