XML::LibXML and XML::Twig are top two. Can't go wrong with either. The first is more DOMy, the second more DWIM/Perly.

I used to go with XML::Twig, but for some reason I started to get annoyed with it. I guess it's a matter of taste. I always use XML::LibXML anymore. It's a bit harder, maybe, to get started with, though. For example, if you look in the SYNOPSIS of its docs, it's difficult to know how to use it. You have to know its classes are (nicely) broken down mostly like the XML DOM, so you sometimes have to search for docs.

Here's maybe a quickstart guide, at least how I use it (I usually encapsulate parts of this in functions):

use XML::LibXML qw(:all);

my $parser = XML::LibXML->new();
# this could also be parse_string
my $xmldom = eval { $parser->parse_file($file) };
if ($@) {
    # problem parsing, die $@, etc.
}

# this is the outermost element
my $doc = $xmldom->documentElement;

# the rest might be familiar if you've used
# the DOM in JavaScript

# findnodes is very useful, but hard to find
# (look in XML::LibXML::Node); this assumes there's
# XML like  <asset><story>...</story><story>...</story></asset>
my $xpath = 'asset/story';    # this can be whatever XPath
my @story_nodes = $doc->findnodes($xpath);
foreach my $story_node (@story_nodes) {
    my $id = $story_node->getAttribute('ID');

    # this is an example where DOM can be annoying
    my ($uri_node) = $story_node->getChildrenByTagName('URI');
    $uri_node->normalize();
    my $uri = $uri_node->firstChild->getData();   # should 1st check i
+t's ::Text !
    $uri =~ s/^(http://)[^.]+(\.example\.)/$1new$2/;
    $uri_node->setData($uri;

    # ....
}

# another thing not so obvious, this is in ::Document
# there are several variations, toFH, toString, etc..
$doc->toFile($newfile);
[download]

Sure. Part of what I like about XML::LibXML is that my JavaScript chops improved as a side-effect of working with it.

I admittedly have little XML experience, but ever since I discovered XML::Twig, I have used it exclusively for XML parsing (reading and modifying). Here are some reasons:

• It is a "Recommended CPAN Module" (http://www.perlfoundation.org/perl5/index.cgi?recommended_xml_modules)
• It has decent documentation and tutorials.
• The author is currently an active PerlMonk who is helpful and friendly.

It depends on what you are going to do; you have to plan a little ahead. Choosing one approach and then later regret it is best avoided ;-) I suggest you make a design first and identify what you really need from the XML arsenal. You only mention the creating and reading of XML data but you probably also want to update and delete parts of the XML documents.

It very much depends on the complexity of your application. What are the required XML features? Do you want to use XPath expressions, apply transformations with XSLT, will you need a validating parser, i.e. are you going to validate your XML documents against some schema (DTD, XMLSchema, RelaxNG, Schematron etc.). What is the expected size of the XML documents etc. etc.

I started out using XML::Simple but soon ran into trouble. It’s only suitable for simple XML stuff (as the name suggests of course!). So for a simple prototype it might be a good choice but don’t expect miracles from it.

As a Windows user my recent experience with XML::LibXML is not too good. In fact I submitted a bug to ActiveState:-( My experience on other platforms is outdated, i.e. 5 years old. At that time some of the standards were only partially implemented which caused us some headaches. I can’t really give a verdict on the current status.

Lately I have been using XML::Twig a lot. However beware, it has a * huge * number of methods and it takes some time to figure out how to use it effectively. A good starting point is http://xmltwig.com/.

Maybe in your situation it is worth considering a proper/native XML database. One of those is eXist. My experience with it is mainly from a Java environment but it seems you can use from Perl as well.

Hope this helps.

It seems to be the most commonly installed XML parser I found.
FYI, the most common is XML::Parser :)

But I've noticed that these modules, like many others, are built as layers on top of XML::Parser -- and wouldn't you know, it's pretty handy, too. In fact, most of the XML apps I've written so far have used just that. It's maybe not the easiest thing to get your head around, but it's certainly easier that XML::Simple. And for those of us who grew up programming relatively "close to the hardware", it's kind of nice to be using the fundamental tools on the fundamental objects. It's also nice, I think, for getting a good understanding about what goes on "under the hood" with those extra-layer modules.

For that matter, depending on what you actually need to do with your XML, the basic module might lead you to simpler, more direct, and more efficient solution. It's definitely worth a look.

I found XML::Simple easy for converting existing hashed data into XML format - but that is all I used it for

I haven't used either of the above mentioned modules yet.

XML::Simple generates more questions here than any other single module. It is simple if you are doing exactly what the defaults expect you to do, but no-one ever does and they all get into trouble as a result. Better to spend the time to learn how to use XML::Twig and use it for the simple stuff and later on for the complicated stuff.

---

Perl reduces RSI - it saves typing

Thank you for that information.

I only used it to convert some hashed data in pre-existing code into XML format and didn't go any further than that; otherwise I am sure I may have discovered its limitations

Note that XML::Twig::XPath, which comes with XML::Twig, gives you a proper XPath engine (it's the one from XML::XPath).

One of the things that I haven't seen mentioned yet in the XML::LibXML vs XML::Twig discussion is that XML::Twig is available via the standard ActiveState Perl distribution, but XML::LibXML isn't (though you can get it by adding the uwinnipeg repository). This means that if you're planning to use LibXML once you leave the prototype stage, but your end product is supposed to be usable on MSWindows boxes later, you'll have to add an extra hoop for end-users to jump through to get it working.

I must strongly disagree that XML::Smart is a good idea, unless your needs are trivial — it is one of the buggiest Perl XML handlers I have had the misfortune to attempt to use. The mere act of setting one element equal to another caused some of the methods to stop working after the assignment. I wish I could provide a more concrete example, but I nuked the code I was testing with after I gave up on making it work reliably.