OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Python and JSON vs XML???

[ 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

    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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS