Dojo Forum

I'm currently using both, XML and JSON, though I've considered migrating
the XML places to JSON, but haven't found strong enough motivation to
change those areas. The XML I use is really only as verbose as you want
it to be. The documents I send back and forth are intentionally kept
simple and small (list lists of items, etc.)

Also I would expect that places where XML is already prevalent, like WS
may be candidates for continuing to use XML format

It seems to be the general trend for web apps.

The main reason people will still use XML is legacy and cross system
architectures. Bear in mind that XML has a very solid standing in
none web base data transfers. If you're building on top of existing
systems then you might be stuck with that.

On Nov 16, 2007, at 9:37 AM, Daniel wrote:

On Fri, November 16, 2007 9:37 am, Daniel wrote:

I have in some situations.

I prefer JSON as well, as it's probably fair to say most people do these
days. I tend to use XML when I'm explicitly developing a more
service-oriented atchitecture, *especially* when there's the idea of the
back-end services being used with something other than a UI (we do a lot
of that here: complex UI's that use the same web services that outside
entities use).

Well, to some degree at least, I am: meaning. More realistic JSON of what
you showed would be:

{ "Root" : [ "1", "2", "3" ] }

Absent context and documentation, that, to me anyway, is a little harder
to understand to a human being. The XML (which is malformed by the way-
no closing tag for the 3rd value :) ) by contrast gives you at
least some hints, and usually it's enough "documentation" to figure most
of it out pretty well. Sure, you can make XML virtually useless to a
human being reading it too (witness the MS Office XML format for a great
example), and you can structure the JSON well enough that it's pretty
obvious what everything is, but I think XML gives this to you a little
more naturally, at the cost of being more verbose of course.

To me, if you're talking data transmission between server and UI, JSON is
the way to go, if for no other reason than dealing with XML in Javascript
is annoying and/or slow. I actually ported a chunk of Commons Digester to
Javascript (it's part of the Java Web Parts project now), which makes it a
lot easier, but it's still not the swiftest thing. JSON by contrast is a
piece of cake to deal with, and pretty darned fast. Perfect choice for a
UI IMO, but the answer isn't always the same if you want to use that
service elsewhere (i.e., is there something like WSDL for JSON? If not, I
don't think it's as useful as XML is for B2B services).

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti at hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

Different strokes for different folks.

JSON has certain advantages over XML. It also has disadvantages. In order to
find the hierarchical data contained in the retrieved JSON object you have
to know the structure before hand. This obviously needs some kind of
'divination'. The other issue is that most of the queries return either
XML,rowsets, or may be text. They are seldom JSON.

Well JSON's good points need support. I proposed somethign like this in my
blog,
http://hodentek.blogspot.com/2007/01/native-support-in-databases-for-jso...

Sincerely,

Jayaram Krishnaswamy

----- Original Message -----
From: "Frank W. Zammetti"
To:
Cc:
Sent: Friday, November 16, 2007 9:58 AM
Subject: Re: [Dojo-interest] General question: Ajax

One of the reasons XML won't go away anytime soon is the main reason
people seem to hate it, and it's the whole schema fun and games.

But for large scale data transfer it's the only way of handling this
currently.

If you're X bank and you need to communicate with Y clearing house,
you need to be able to make sure that you are sending what they expect
and they need to be able to confirm that what you're sending they
should be accepting.

For 97% of 'web' based Ajax work, this is totally irrelevant. Most
Ajax work is small snippets of data to update pages, it's not large
scale data transfer.

As you say, it's really apples and oranges, it just so happens you can
make Juice? with both.

On Nov 16, 2007, at 10:16 AM, Jayaram wrote:

Jon Sykes wrote:

Well, I certainly wouldn't want XML to go away. I wouldn't want my
office suite to save my documents in JSON, and with XML you can use XSLT
and other neat tools (yes, I like XSLT). I was just thinking of Ajax,
where bandwidth is usually a scarce resource.

Cheers,
Daniel.

On Fri, November 16, 2007 10:16 am, Jayaram wrote:

Yep. As with most things in the world of software development, when you
try to come up with the One True Answer(tm) to every question, you've
already made a bad decision. I'm sure we all have stories about when one
format was right vs. the other and stories about when the opposite was
true. And in both cases we were probably right! :)

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti at hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

There are 2 things going for XML:

1) Legacy data backends.
2) XSLT support.

#1 is obvious --- if you have an existing data service, you may want to
reuse it.

#2 --- sometimes it is simpler to transform your data on the client
before consuming it. It is a powerful technique in some cases.

Of course there is more to XML, e.g., data validation and streaming
support, but they are not used in the browser. At least there is no API
for them.

For everything else use JSON.

Thanks,

Eugene

Daniel wrote: