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 03:06]:

> For some time now we've seen the JSON "fat-free alternative to XML"

> I'm not sure what to make of all this, other than that there is a
> lot of dissatisfaction with the status quo with respect to XML and
> programming, and a lot of experimentation going on to address it.
> Some approaches might threaten XML's story as a universal data
> interchange format, or might revitalize it by scraping off the
> cruft, we shall see.  A few questions I'd be interested in hearing
> others' take on:

> -  I'm trying to understand whether JSON has a value proposition
> outside of AJAX scenarios. Is JSON or Python  significantly faster
> to parse into usable objects than data-bound XML?   Is anyone
> suggesting it (or some Pythonic equivalent) to address the types
> of use cases that binary XML is targeted at?

    Doe JSON address binary?
    It serializes to JavaScript data structures populated with
    literals, so it can only handle text data.
    Binary data would have to be encoded to text, just like XML.

> - Could something like JSON become Yet Another Infoset Serialization
> Format You Have To Deal With if binary XML gets momentum and opens up
> the possibility of alternative serializations for different
> environments?

> Or is it just conceptually easier to deal with a single object
> syntax rather than fooling with XML when you have the luxury of
> working in the same dynamic language in all parts of a system, so
> and this really isn't a threat to XML's value proposition?
    Much easier. As a Perl/shell programmer, cofiguration was most
    often an included script. Why an XML parser requirement when I
    can create a file with something like so:

    @options = ("a", "b", "c");

    If I'm exchanging information with other Perl programs,
    Data::Dumper is available, and much faster that any of the XML
    parsers. No bindinging, etc. One function call out. One eval
    back in.
    When reading the examples at the JSON page where they compare an
    XML configuration to a JavaScript configuration, one does not
    see any great advantage in legibility. 

    If you've been hacking JavaScript for a couple months, and
    you've got curly braces burned into your retnas, the JavaScript
    is going to speak to you.

    If my program is a Perl program, I'm not going to store my
    information in JavaScript, however.
    It would be nice to emit JavaScript for JavaScript programs, of
    course, but not as a storage method. It's slow, and you are
    going to run into data binding issues anyway.

> - The idea of programming languages in XML syntax seems to be on the
> wane (other than XSLT of course, which is not *really* a programming
> lanuage even if it is Turing-complete).  The idea of integrating XML
> ideas into programming languge syntax seems to be on the rise,  e.g.
> the JSON and Python stuff, E4X, C-omega and friends, Java's apparent
> plans in the Dolphin release, etc.  Anyone disagree?

    Other that XSLT, the only programming langauges I know of that
    are XML based are Ant, which is not turning complete, and Jelly.

    Ant is unpleasant. Binding to the element names is cute, but
    probably not a good idea. Jelly is painful.

    Thus, I use XSLT 2.0 for all my XML generation needs. I'm using
    it generate my Ant scripts, so that my Ant scripts contain no
    logic. Since I've got it around for Ant, I'm now using it as
    for more general purpose scripting langage, to generate
    properties files, and other configuration output.

    In this application, Java build configuration, XML for XSLT is
    behaving a lot like JSON for JavaScript, in that I can very
    quickly "eval" an XML configuration file, and very easily emit
    an XML configuration file. 

    Serializing a scripted langauge for later evaluation is
    something that programmers do. I don't see how serialzed REXX,
    say, or QBasic becomes a data exchange standard.
    JavaScript is all the rage these days, owing to AJAX, but it is
    still JavaScript. It's a language for a particular platform, and
    it's fortunes will rise and fall with that platform.

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