[
Lists Home |
Date Index |
Thread Index
]
* Michael Champion <michaelc.champion@gmail.com> [2005-08-25 13:27]:
> On 8/25/05, Pete Cordell <petexmldev@tech-know-ware.com> wrote:
>
> > Whether the observations made below represent a genuine move away from XML,
> > or represent a small pocket of newly discovered dissenters I don't know.
>
> Neither do I, that's why I'm asking. If these are fragmented domains
> in which XML just isn't needed, I don't think XML stakeholders need to
> think too hard about how to react to or accomodate JSON. Nobody ever
> said that XML was good for everything, just that its network effect
> makes it good enough for a lot of things. If the native tools in a
> specific environment are more suitable for things like config files
> and quickn-n-dirty client/server protocols, I can't think of too many
> reasons to suggest XML over than JSON, Python syntax stuff, etc..
> Once you start having to talk across platforms, however, you start
> getting benefits in return for the XML tax.
I'm going to repeat myself, probably, but maybe with some new
insight after mulling all day, so...
About the only thing that JSON buys is a ready parser in the
client side, on that works on all browser platforms.
But serialization? It's not there is it? I'm going to say that I
never ran across it. So the only gimmie is a "free" parser.
That's nice, but you are not going to remove XML from a browser
application. The document you twiddle to get your GUI effects is
W3C DOM. XML (or HTML, but once it's DOM it looks the same) is a
huge part of your application, you are going to have to parse
it, generate it, serialize it.
You've parsed your JSON into a tree (not a graph) of JavaScript
objects. Now what? You're going to turn them into XML now,
aren't you? Because there's no other way to view the data.
You're forgetting, or have yet to learn, that the ONE TRUE
OBJECT in a web application is the W3C DOM document that.
Then on the server side, unless you have a server application in
JavaScript, and I can't imagine what you could have done to
deserve that, you're going to include a non-native parser, and a
non-native serializer. No ready query, transform, or storage
facilities.
Plus, none of the i18n stuff that I'm learning about.
As I noted, somewhere else, I've used the eval() in my scripting
languages for quick configuration, and squirting some
configuration into an outgoing web page is a valid use for JSON,
but that's the limit.
--
Alan Gutierrez - alan@engrm.com
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
|
