[
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
|
