These questions seem to be falling into the same trap that Dare
complained about.  JSON is a simple single solution to a whole set of
problems.  It addresses cross-domain access.  It is fast.  It is easy
to use.  On every account, XML fares worse.

JSON is just object serialization.  How often do your object model's
have 'parent' pointers?  Given the success of simplistic ref-counting
GCs in Perl/Python/etc, I think it if apparent that circular pointers
are not particularly common and not hard to live without.  (To
clarify, a reference-counting GC scheme leaks memory when there are
circular pointer references.  The program needs to break the reference
loop before the gc would collect any of the objects.)

Aside from the cross-domain issue, I think XML also missed the boat by
not providing a canonical 'object serialization', akin to JSON.  Part
of the explosion of JSON is due to it's low barrier to entry.  A
web-app developer can get something up-and-running with JSON, much
more easily that XML.  It requires less code in the browser, and
doesn't involve dealing with 2 data-models (javascript and XML).  If
they could have gotten the same benefits with XML, less people would
be jumping on JSON.  The cross-domain issue only really comes up when
building an aggregator or a mash-up.

A few people will complain that object-serialization = tight-coupling.
 One one hand that is true, but given that web-apps are redeployed on
each use, that is not nearly as much a concern as it is with
traditional thick-client apps.  Also, where tight-coupling really
hurts is when the wire format is the server's objects.  If the objects
structures serialized are client oriented, it already is most of the
way toward loose coupling.

> Will an eval'ed JSON object(s) eventually look like a DOM object?

I sure hope not.  I've always found the DOM a horribly awkward
programming model.  It was a valiant attempt at building an API that
supports both text-markup XML and data-serialization XML, but the
strain from being stretched by two very different use-cases shows.
Very few developers want to program against DOM objects.  They want
Javascript objects.  Most code would just parse the DOM into
Javascript objects anyway.  JSON skips an entire (expensive) step,
saving development and runtime costs.

-derek


On 1/4/07, Robert Koberg <rob@k...> wrote:
> Hi,
>
> It seems a lot it is being said about JSON being a better browser format
> than XML. Dare Obesanjo makes the best points in favor of JSON - mainly
> that you can cross domains easily.
>
> But with JSON:
>
> - how do you get the parent object?
> - how can you go directly to an object? (perhaps it is deeply nested in an
> array, in an object, in an array)
> - how do you transform it for a view? do you write your own transformation
> language each time?
>
> Does any of the above matter for JSON?
>
> Will an eval'ed JSON object(s) eventually look like a DOM object?
>
> -Rob
>
>
> _______________________________________________________________________
>
> 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@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>