The short answer is: Don't use XML::Simple.

The longer answer is: Show us your code.

The long answer is: Sometimes, in your input XML, there is an element that never repeats, and in other input XML, it repeats. Because XML::Simple makes some guesses about your XML, it is sometimes wrong. Use the ForceArray parameter to tell XML::Simple about which elements you think should repeat.

I am happy when these modules produce perfect syntax-compliant output, but much less happy when they choke and fail at some mistake upon reading the input. Come on, why isn't it apparently possible to implement a DWIM principle in these formats?

Quite a few times, I have had to use my own poor regex solution because these modules are usually unable to cope with only very slightly deviant format.

I understand that there is no perfect solution to this problem, but there could be at least a "strict" and a "lenient" mode in these modules to cope with different situations. I may be wrong, but I do not know of any of these modules having such different modes.

Come on, why isn't it apparently possible to implement a DWIM principle in these formats?

This actually makes me angry. Well, not really but it's fun to pretend. The sloppy, half-assed XML that exists because of HTML and sloppy, half-assed programmers who ignored the standard, has caused many of us tons of woe. If you are being served broken JSON or XML, push back, push back hard. There is no excuse for anyone generating garbage here and the more lenient the tools are, the more the heap of trash will grow to block out the sun!!!

Boo! But really. Don't accept broken XML or JSON.

Yeah, you're probably right, Your Mother, on the deep side of things, it is probably not a very good idea to ask for more lenient tools. But I still wish I had them, sometimes I just can't reject bad data formatting from the client.

I don't do much JSON, but the requirement for XML is to die on errors. No guessing, don't be polite about it, just up and die. CSV is a little fuzzier, but I tend to think it's not a bad idea to die on bad CSV. When I try to read CSV with the settings a little bit wrong, I tend to get something so horrific that I prefer that the reader just die.

HTML is a different story - there's enormous amounts of bad html out there and the convention unfortunately is that browsers will tolerate it. In a fair bit of screen-scraping, I haven't really run into problems with HTML parsers barfing, but I think I'm also mostly reading machine-generated HTML (though without guarantees that it's any good).

the requirement for XML is to die on errors. No guessing, don't be polite about it, just up and die.

I'm no big fan of XML, but I think this is the biggest strength of XML and related tools. Either your XML is well-formed, or your tools start to complain. Tools that generate tag soup instead of XML and name it XML are just broken and need to be fixed or must stop calling their output XML.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I am not sharing the link here as it's from activestate docs and I am not sure about the cpyright and all, but if you go to their docs in FAQ section and search for XML::Simple then you'll get some specific details about ForceArray and KeyAttr options which might be casing trouble for you (As suggested by Corion).

Also try using print Dumper() on your data to see what all is there. Try to print the elements in hierarchical order starting with the problem element, climbing up to the root element.

I had almost similar problem with XML::Simple and these were the steps I follwed (suggested by monks here) to find what exactly was going wrong. I wanted to switch to other modules but being in restricted environment was forced to use XML::Simple. So again as already suggested by Corion, (and if you have that option) go for some better modules like XML::Twig which was suggested to me by many.

I hope this helps you.