

Python module that makes working with XML feel like working with JSON - dagw
https://github.com/martinblech/xmltodict

======
hafabnew
Cool, although LXML (mature, fast, reliable, generally awesome) can do this
(and more): [http://lxml.de/FAQ.html#how-can-i-map-an-xml-tree-into-a-
dic...](http://lxml.de/FAQ.html#how-can-i-map-an-xml-tree-into-a-dict-of-
dicts)

It also has the 'objectify' API, where you can access XML nodes via regular
object access (i.e. `access.nodes[0].like.this`).
[http://lxml.de/objectify.html](http://lxml.de/objectify.html)

~~~
raverbashing
Good, I had never seen this transformation tip in LXML

But usually, yes, LXML is "good" meaning it's the least worse way of dealing
with XML

Also, it has some idiosyncrasies, like insisting on adding the namespace on
tag names, so you end with something like
{[http://example.com/your.xlsd](http://example.com/your.xlsd)}.index (I don't
remember it exactly and I don't have an example here with me)

~~~
toyg
Correctly handling namespaced QNames is a requirement, not a bug. It makes
things awkward at times, but that's a job for lib writers to provide decent
interfaces.

I haven't used LXML in a while, but ElementTree, for example, forces you to
use the QName in XPath expressions, which is technically correct but a huge
pain; it would be nice if there was a ScrewNamespace option that would allow
"simple" searches, although this might blow up in your face one day (when two
namespaces define the same element name, and your xpath search brings up
elements you didn't really want).

~~~
raverbashing
Actually the short name worked for the searches, the problem was reading
element names from a subtree

It's not as much as dodging the requirements but rather an inconsistency in
the API.

------
toyg
There are umpteen versions of this sort (there was even an ActiveState
cookbook recipe at one point, I think). The problem is that they tend to be
coded up with certain requirements in mind, without really going through XML
specs, so inevitably you'll find places where they break down.

In this case, I don't see any namespace in examples nor (more damning) in unit
tests, which tells me it's likely going to fail on complex documents with
multiple namespaces.

------
clarkevans
In 1999, there were a group of us working on a subset of XML (we called SML at
the time) that had a simpler information model and syntax limitations so it'd
be easier to work with. It seems that any simple encoding of XML onto JSON
might find the deliberations interesting (if quaint and outdated):
[http://tech.groups.yahoo.com/group/sml-
dev/message/0](http://tech.groups.yahoo.com/group/sml-dev/message/0)

~~~
fosap
Today there is MicroXML.
[http://www.w3.org/community/microxml/](http://www.w3.org/community/microxml/)

------
dkhenry
I think a better title would be make working with XML feel like native
dictionaries, There are many ways for interacting with JSON dictionaries are
only one of them.

For example you can do XPath style interaction with JSON in python which for
many things works out just a good if not better.

------
fr33k3y
There is XML::Simple perl module since a century ago and it's ruby "copy" with
the same name since long time ago also.

I've used the perl one and it only makes sense in very simple use-cases.

~~~
nmcfarl
I’ve used the perl one as well. And while I’ll agree the XML handled needs to
be simple, I’d say the the use case needn’t be.

At one job dealt with 10 and 20 Megabyte XML files on a daily basis - and I
never thought of throwing XML::Simple at those. The results would be anything
but Simple.

On the other hand I’ve run production code for years with an XML::Simple
client to XML only RESTish API with ~100 endpoints. And that suckers still
critical infrastructure - and barely being touched. Just humming along.

~~~
tootie
XML::Simple was glorious for working with 1-100K documents. I've used it on
bigger docs and it actually handles them pretty gracefully although I've never
tried at scale.

------
Erwin
10 years ago (he was just about 16 then!!), Aaron Swartz wrote this which has
been very useful to me:
[http://www.aaronsw.com/2002/xmltramp/](http://www.aaronsw.com/2002/xmltramp/)

Since then the builtin interfaces have improved and I use mostly
xml.etree.cElementTree

------
zamalek
What about namespaces? If you are not using namespaces you are very likely
using XML as the wrong solution for a problem - still your library has use for
helping cleaning up old code that did use XML as the wrong solution. Good
work!

~~~
eli
The overwhelming majority of XML I encounter in the real world does not use
namespaces.

------
anaphor
Doesn't this defeat some of the advantages of using XML though? Like Xpath?

~~~
raverbashing
Using XPath is good but it's a small comfort in the bloated and
overcomplicated world of XML

I don't see any advantage in using XML to be honest

~~~
emn13
I've never understood this criticism. XML is quite simple - perhaps too
simple.

If you're really offended by needing to repeat an element name in the closing
tag... well... that's not exactly a serious criticism is it?

I mean, you could make various reasonable criticsms - XML sure isn't perfect.
You might say the object model maps to documents, but not so well to typical
programming constructs such as unordered hashes or ordered lists of unnamed
items. You might complain that its data model is too simple in that it can
only easily represent printable text-strings not binary data, numbers, dates
etc. You might complain that namespaces are a hassle in many API's. You might
complain that the distinction between attributes and elements is odd and
somewhat arbitrary.

But bloated? You're just ranting.

~~~
mbell
> XML is quite simple - perhaps too simple.

I disagree pretty strongly with that statement:
[http://www.jelks.nu/XML/xmlebnf.txt](http://www.jelks.nu/XML/xmlebnf.txt)

XML's grammar is far from simple.

~~~
bct
A significant portion of that grammar is for parsing DTDs, which isn't really
a fair inclusion.

~~~
mbell
why?

------
Dru89
I haven't had much of a chance to play with it yet, but I wonder how it would
handle a query to find all the "baz" elements for a structure like this:
[http://pastebin.com/m7qTy8kw](http://pastebin.com/m7qTy8kw). Does it just
support a loop, or possibly something similar to xpath like
/document/foo/bar/baz to get an array of all of them. (Perhaps
document["foo"]["bar"]["baz"], though I think that would break other things.)

------
wulczer
We wrote a similar utility for our ORM-for-SaaS library some time ago, using
lxml if available and falling back to ElementTree:

[https://github.com/ducksboard/libsaas/blob/master/libsaas/xm...](https://github.com/ducksboard/libsaas/blob/master/libsaas/xml.py)

Bear in mind that both approaches are lossy - trying to support every XML
quirk would quickly lead to reimplementing the libxml wheel...

------
cronin101
The Ruby equivalent would be XmlSimple: [http://xml-
simple.rubyforge.org/](http://xml-simple.rubyforge.org/)

~~~
eCa
And the Perl equivalent is XML::Simple:
[https://metacpan.org/module/XML::Simple](https://metacpan.org/module/XML::Simple)

~~~
fuzzix
I would not recommend XML::Simple, there are various cases (not even that
uncommon - say having an attribute and an element of the same name) where it
breaks down.

It may be awkward to use at times, but XML::LibXML is robust and consistent.

------
brianmcconnell
I work with a lot of translation services. While the machine translation
services are easy to deal with, the professional translation agencies _love_
XML. They also generally know f--- all about building usable web APIs. This
looks pretty useful.

------
lechevalierd3on
This reminds me of PHP's SimpleXML
[http://php.net/manual/en/book.simplexml.php](http://php.net/manual/en/book.simplexml.php)
Which belongs to the good parts of PHP.

------
level09
Does this mean we can simply convert any xml api to a json equivalent by just
json.dumps(xmltodict(xml)) ?

I am going to give it a try.

------
larvaetron
I used this to build [http://showhen.me](http://showhen.me) and it worked very
well for my use case.

------
watchdogtimer
I used this to parse some XML when creating a shipping calculator. It was a
huge time-saver.

------
pknerd
I recently used it for a project and I am quite a happy consumer of this
library.

------
mathattack
This seems so obvious that I wonder why it wasn't done before. Well done!

~~~
martinblech
Thanks!

------
vittore
There are two older similar projects - beautiful soup and untangle.

------
xmjee
Made a port for FreeBSD, thanks much!

------
bonemachine
Which is a pity, because... XML is nothing like JSON.

