If you need to deal with XML, first, we’re very sorry.

Perhaps true. It is used in a load of places where it's overkill. It's effectively a data structure with an extra 'dimension' at each level - a node has:

• content
• child elements
• attributes

XML is about the only way you can easily do all three at once, but ... how often is this necessary? XHTML type documents is perhaps the example I can think of - and that's a pretty big use case - but actually most uses the looser HTML spec rather than XML. (Major difference is - XML is much stricter about tags, ordering/closing/nesting). That's why I think XML is here to stay, but would generally agree with your assertion - most use cases I've seen it JSON is the better choice for data object transfer (API) and YAML for flat file (config).

But either way - once you have things like xpath and 'directory style' navigation (parent/child/sibling) of your XML doc, it is a lot saner. Certainly more so than trying to flatten part of it's dimensionality into a less complicated data structure like the perl native ones.

Yes, I agree with you and, of course, my post was only half serious.

The main reason for my frustration about XML is that I relatively frequently have to fix incoming data to make it valid XML before I can process it with a state-of-the-art parser. And that is a nuisance especially in view of the fact that this incoming data is in fact simple enough not to require any of the XML heavy artillery.

Nested hashes and arrays could be forced into all three, albeit perhaps at the expense of some awkwardness. After all, it's all structured data. Below is just a quick example and I'm not writing this node to promote writing code to support this data structure. It's certainly not impossible, though, to denote these things.:

my %data = (
    'attributes' => {
        '_name' => 'mydata',
        'height' => 50,
        'width'  => '80%',
    },
    'children' => [
        { 'attributes' => { '_name' => 'bob', ...} ...},
        { 'attributes' => { '_name' => 'tom', ...} ...},
    ],
    'content' => 'yadda yadda ...',
);
[download]

Whether that's something you'd want to process later is another issue. Some people like to put a lot of predetermined information about their data into their code. Others like to keep the data as self-describing as possible and keep the code very general to work with that. There are strengths and weaknesses to either approach.