
XML: Contrary to popular belief, it doesn't always kill babies - jancona
http://www.thurn.ca/xml_contrary_to_popular_belief_it_doesnt_always_kill_babies
======
Groxx
> _There just isn't a really nice way to represent a tree structure in
> something like JSON._

 _What_? They're trivially identical! Here, an algorithm to convert from XML
to JSON:

    
    
      < => {
      > => }
      attribute="value" => key:"value"
      contents =>  $:[{},"",{},etc,"look ma, multiple text nodes!"]
      node name => #:"name"
    

Actually, there's one that most JSON parsers can do that XML can't:

    
    
      key: function(){alert("Oh joy, someone used <em>eval!</em>");} => ???
    

edit: thought of another one:

    
    
      {"spaces in <key name{w00t}>":value} => ?
    

I have absolutely _no idea_ how people come to the conclusion that XML somehow
magically does X while nothing else does. XSLT can be modified to work on
JSON, schema definitions too (how about: <http://tools.ietf.org/html/draft-
zyp-json-schema-03> , or a pre-defined set of rules like JSON-RPC?), and XPath
== CSS-like selectors with a different set of characters.

The only difference between XML and JSON is the character set and the tool-
chains available. JSON is rapidly gaining the same capabilities through tools,
while XML has _tons_ of non-compliant libraries (I've had to deal with other
people's XML APIs in cases where attribute order mattered (likely hand-rolled,
I know), or they couldn't parse a standard schema doc, or they couldn't handle
namespaces properly).

About the only thing you can say is that JSON is XML "lite", currently, and is
a new chance to do things differently / correctly. The problems many people
have with XML relates to just that - non-compliant libraries that clog the XML
tubes, making working with it a total crap-shoot often enough that it's worth
avoiding.

~~~
Homunculiheaded
I once explored the topic of "xml is just verbose s-exps" with someone who had
no lisp experience. His first response was that it would be impossible to just
use lisp in place of xml because you would then have to implement a minimal
lisp parser into any language that wanted to make use of data stored in
s-exps. I then pointed out that you have to do the same thing for xml or json,
it's just that we've become used to standard tools existing to do this.

That's actually where I find that XML is the most dangerous. People just take
it as a fact of the universe that XML exists and make so many assumptions
about how it solves a particular problem that they don't even stop to think
"could there be a better way?"

~~~
GFischer
I'll admit my ignorance about the existence of S-expressions (had to look them
up here: <http://en.wikipedia.org/wiki/S-expression> )

I've used XML because .NET has a parser, and I'll probably use JSON because
parsers are widespread... are there good standard parsers for S-expressions
for .NET or other popular platforms?

A quick googling sends me here

[http://stackoverflow.com/questions/3051254/parsing-lisp-s-
ex...](http://stackoverflow.com/questions/3051254/parsing-lisp-s-expressions-
with-known-schema-in-c)

which makes me believe.NET can't natively process s-expressions with ease, and
that's a HUGE minus for me.

~~~
dfox
Few lines of code in the last answer is actually everything you need to parse
(reasonable subset of) S-expressions. So there probably isn't any general
purpose programming language that cannot handle S-expressions with ease.

That holds if you want to use S-expressions as data exchange format (or like
network protocol as is done by Subversion). Parsing Common Lisp source is
entirely different matter.

~~~
GFischer
It does seem you can handle them, but we .NET people are lazy (as in, Larry
Wall lazy <http://en.wikipedia.org/wiki/Larry_Wall> ).

I agree with the poster's reply to that: "Yes I agree that this is simple and
fast, but.. What I really want is a 1-D list of my own object types." I get
that when using XML web services with .NET (though mostly when consumed with
other .NET or similar languages !!! which goes against it being an universal
data transfer language )

------
snprbob86
I have a strict NO XML policy in any codebase that I control.

It's not because I think that XML necessarily always kills babies, it's
because I think that XML has never once been the best choice. "Does everything
well enough, but I don't need to learn or develop a new technology" is not a
valid reason to use it and there are plenty of valid reasons not to use it.

That said, XML has killed every baby I've ever exposed to it.

~~~
bpodgursky
Do you count even things like ant buildfiles? I won't say that editing them is
fun, but it's no worse than configuring any other build system.

~~~
xiongchiamiov
Really? In my (admittedly limited) experience, ant was much more of a PITA
than things like Rake and Scons.

------
DjDarkman
> Computers adore XML. It's nice and easy to parse, so structured and precise.
> Computers love that shit.

It's not the easy to parse, without interpreting complex schemas that are
sometimes missing. It's not even easy to map, you have the attributes, the
children and inner text, this makes it a pain to map to native objects.

There may be good tools for this, but I wouldn't call parsing it easy
especially compared to other formats out there.

~~~
_delirium
The fact that you can't parse it with standard parsing tools doesn't seem like
a win on the parseability front either. Not its biggest problem, but nothing
in this use-case made it _necessary_ to define a syntax that tools like
lex/yacc can't parse. The core problem is that matching up start/end tags
can't be done in a context-free language unless there are a finite number of
tags (it's isomorphic to the problem of checking for palindromes). You'd need
a parser-generator that lets you do backreferences (which makes it not
context-free), so you could write a definition along the lines of:

    
    
      element = '<' + element_name + '>' + element + '</' + $1 + '>'
              | nil
    

Either that, or a hand-rolled parser, which is in practice what XML parsers
are.

------
Homunculiheaded
The more I work with XML, the more I'm convinced that Naggum was dead on:
<http://www.schnada.de/grapt/eriknaggum-xmlrant.html>

XML is, for me, the classic example of the problem of reinventing things
badly. The sad thing is that we've barely been programming for 60 years and
we've already reached the point where much of our work is wasted in this
process.

~~~
andolanra
"The essence of XML is this: the problem it solves is not hard, and it does
not solve the problem well." —Philip Wadler, "The Essence of XML," presented
at POPL 2003

And he knows what he was talking about—he was one of the people who worked on
XQuery, after all.

------
krig
> Microsoft might not be totally crazy for basing their docx file format on
> XML. Honestly, I'd expect them to be uniquely qualified by years of
> hindsight, shame, and regret to design a document format.

I don't know if unparallelled failure is a good indicator of design ability...

It's amusing though, pretty much the only area where the article actually
claims XML doesn't kill babies is in representing trees. Ehm, how about sexprs
for hierarchial data representation?

My personal opinion is that XML _always_ kills the baby, and nothing I've
experienced has made me reconsider that assessment.

------
nivertech
For somebody who want to make XML shorter and more human-readable:

1\. Use more attributes, i.e.:

    
    
      <employee first="Steve" last="Jobs/>
    

instead of

    
    
      <employee>
         <first>Steve</first>
         <last>Jobs</last>
      </employee>
    

2\. Use Camel case instead of '_', i.e.:

    
    
      <MyElementName>XXX</MyElementName>
    

instead of:

    
    
      <my_element_name>XXX</my_element_name>
    
    

3\. Use sane namespace prefixes.

4\. Write XSD schema (or generate it from example XML document) - Tools like
XMLSpy really helpfull in filling complex XMLs.

~~~
cperciva
Some of us find unix_style names far more readable than CamelCase. Underscores
are almost spaces and make it much easier to recognize where each word starts.

~~~
nailer
Wouldn't unix style be uxixstyle?

------
udp
Nicely unbiased. Not sure about the title, though, since the article is (quite
rightly) more about why _not_ to use XML.

------
fedd
will someone write that java or at least jvm doesn't kill babies?

i remember how someone saw an xml config in my java-based software demo and
judged it's innovatiiveness based on it. and it was not even mine, it was
standard web.xml!..

i think the main thing is not be religious about formats.

~~~
bpodgursky
If they're dumb enough to judge the innovativeness of software based on
something like that, their opinion is probably irrelevant.

~~~
nailer
If the software doesn't care about ease of configuration, what else doesn't it
care about?

------
orls
"When your only tool is XML, every problem looks like it's a schema
declaration and a few XSLT transformations away from a nail"

This almost exactly describes a Project Manager I've worked with -- he has had
experience with a CMS system that was entirely XML-document based, and sees
_almost every_ problem as solvable with XML/XSLT, and pushes it one his teams.

Which is a good example of why project managers shouldn't be allowed (or at
least not depended on) to make technical architecture decisions. We've ended
up doing a giant site search project based on huge XML indexes...

------
contextfree
Five years ago I was a hardcore XML-hater (and an even more hardcore SOAP/WS-*
hater), but these days I've sort of become an apologist for both. Not that XML
has gotten any less ugly, I'm just annoyed at people mistaking superficial
problems with deep problems, and start over every five years or so with a new
syntax or something thinking it'll make those deep problems go away.

------
TeMPOraL
In what way "computers adore XML"? Well, it can represent trees (and so can
S-expressions), but its verboseness makes the files bigger, parsing more
computation-intensive and memory consuming.

------
jister
Technologies has its pros and cons so yeah, XML when used properly, doesn't
kill babies.

