It can also take a little time to figure out its ideas of attributes vs. sub-elements if you're taking in XML and producing another XML file as output you're expecting to look the same. Your specific situation doesn't sound like this will give you any issues.
In all, XML::Simple is named well. It's good for quick work with XML data when the requirements are simple.
For an anecdotal case, I wrote a configuration manager for an existing project in another language (ActionScript). That project initially cared about order of elements, which I didn't realize until I had written most of the config manager. I considered dumping XML::Simple and rewriting my project to use something else. Since I had the source to the other project and a license to modify it, I decided to check into why the order mattered. It turned out that a simple 3-line change to the existing project made it work with the sub-elements in question in any order. That was much easier than rewriting the entire configuration manager, but now I've forked the original project.
I submitted the change upstream, but I'm not sure the developers have done anything with the submission. It's closed source (my employers at the time paid for a source license for that version), so I'm not sure I'll ever know.
If I had bothered to figure out XML::Simple was going to require this workaround, I might have written the configuration manager using another module. Still, though, a three-line change isn't difficult to patch into newer versions of the project it configures, so I'd probably still have rather "fixed" the main project rather than worked around what I consider to be its brokenness.
In reply to Re^3: perl implementation of Fast Infoset, or other binary XML representations?
by mr_mischief
in thread perl implementation of Fast Infoset, or other binary XML representations?
by bcrowell2
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |