Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
