Re: XML::Simple needs to go!

[Laurent_R]

<Mode Troll On>

The problem might not be with XML::Simple, but simply with XML, which no sane or even half-sane person would have ever designed, but of course a committee did, and some ignorant management people thought it would be great.

We should really get rid of XML, and that would solve the issue of XML::Simple. ;-)

Things like JSON, YAML or CSV are so much better for 99% of the cases. <Mode Troll Off>

[Discipulus]

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


brian d foy

L*

[Preceptor]

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.

[Laurent_R]

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.

[mr_mischief]

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 ...',
);

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.