While that is generally true, especially for generating XML files, i have yet to find another XML parser that is as simple and easy to use. XML::Rules is somewhat promising, but still adds a lot of extra complications.

When it comes to parsing config files, i generally don't give an f### if it validates against some XSD schema (and in usually don't bother to even create one). I don't need "sequential parsing" or "streaming" because of the file size. All i want to do is turn that file into a hashref. And i don't care about all the "advanced" XML stuff like namespaces. The only reason i'm not using JSON is because i find XML easier to read and write by hand.

For some time now i've been thinking of either forking XML::Simple (and rip out all the "write XML files" stuff) or writing a wrapper for something like XML::Rules that emulates the XML::Simple behaviour as close as possible. In my humble opinion, we really need a module that's as simple as XML::Simple, at least for reading XML config files. Basically the equivalent of simplicity to parsing a JSON file.

> Basically the equivalent of simplicity to parsing a JSON file.

The problem is the DOM tree of XML doesn't correspond 1:1 to common data structures (scalars, arrays, hashes).

<r ch="1">
  <ch>2</ch>
  <ch>3</ch> <!--
  <ch>4</ch> -->
</r>
[download]

What data structure do you expect?
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

I expect that all of the "ch" elements in this tag will be put into an array. But what i really expect is that the XML doesn't come with such a stupid and confusing design in the first place. I can't see a semantic reason for this type of XML design. If someone sends me a design like this and does not have a very, very, very good explanation and a very solid reason behind this, i will just refuse to accept that design.

Just because something is possible does not mean it is acceptable. Like using obfuscation in production code.

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

While I personally do think XML::Simple is sometimes (but rarely!) ok to use, for reading very simple XML files that happen to be structured in a way that the module does handle well (which one can make sure of via a Schema), IMHO the major problem of XML::Simple is that it does not handle the structure of the XML file changing very well at all. Someone may start out a project with a simple XML file that the module can handle, but as the project grows and the XML's structure becomes more complex, one begins jumping through hoops to bend the data structure back into shape. Another problem is that the module's name lends itself to the misunderstanding that it's a simple way to read arbitrary XML files, which is most certainly not the case. Both of these cases are well-represented across various threads on this site, and in most cases one is left arguing with the wisdom seekers who don't necessarily want to move away from a module they've already invested in. Hence the recommendation against the module in general makes sense - it's one of those "only use this if you know what you're doing and why" things.

XML::Rules is somewhat promising, but still adds a lot of extra complications.

Really? I personally don't think so; I have several XML::Rules examples on my scratchpad.

True, for that reason I do not use XML::Twig for small and simple files but prefer XML::Simple.
So having a solution to simply get XML data and put it in a hashref is exactly why I ended up with XML::Simple.
I did not yet have any problems with the parsing side of XML::Simple and did not realize the "PLEASE DO NOT USE THIS MODULE IN NEW CODE." part.