gildir,

Interesting question, hard to answer I fear.

Traditionally people attacking an XML problem in Perl, build a single purpose module based on an XML Parser, for example XML::RSS or RPC::XML or SOAP::Lite. The module can deal with all the logic of converting XML into Perl data structures, and converting Perl data structures back to XML. A quick hunt round CPAN will show that there are lots of these modules there already.

An alternative approach is to use Perl to handle the logistics, but let the data stay in XML. For example you can pretty much convert any kind of XML into XHTML or raw text quite easily with XSLT, you don't have to do it programmatically in Perl. As it happens Perl has some good SAX and XSLT technologies to use that are part of AxKit: XML::LibXML, XML::LibXSLT and XML::SAX. You just have to learn SAX or XSLT...

Whatever the reason, unless you have a pressing reason I would not use XML::Parser to base a new module on, the c library it's based on (expat) is getting old, and it does not fully support all the current standards, and it does not support emerging standards. Instead I'd look at XML::LibXML which is very fast and very modern.

Additional resources to look at:

Here:

• Which XML module to use?
• XML parser
• XML and Perl
• Why is Perl so bad with XML?
• XM-Hell
• XML Module decision tree?

CPAN:

• XML::LibXML and XML::LibXSLT are c based, and very fast - a particular favourite
• XML::DOM if you need a W3C DOM interface
• XML::GDOME if you need a DOM level 2 interface
• XML::Parser if you want low level access to your XML (bit old now)
• XML::Sablotron another fast c based parser/XSLT engine
• XML::Simple a classic simple interface to XML in Perl
• XML::TreeBuilder a useful yet under used XML tree manipulation module
• XML::Twig another Perlish XML interface

Elsewhere:

• Perl and XML on XML.com
• on XML.com
• Perl-XML mailing list
• Mirod's Ways to Rome
• Using XML Modules in Perl
• http://www.perlxml.net/ Perl-XML FAQ - Dead Link

Note: Bits of this post are shamlessly taken from earlier posts by me....

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

At this point I would not use XML::Parser as the base for a new tool, I would go the XML::LibXML way, unless libxml2 does nor run on the system you plan to use.

If you need W3C schema support note that Andy Wardley just released []. I (and I am not alone in this, see this (long!) thread on xml-dev) don't like W3C schemas though, Relax NG (pronounced relaxing) seems like a much more sane way to go, see this message from James Clarke.

Should I subclass XML::Parser?

No, that kind of approach is deprecated these days.

If you want access to the XML contents as an event stream (like XML::Parser's Handler interface) then the best option would be to use SAX. Your code would use XML::SAX::ParserFactory to get an object capable of parsing XML. This object might use XML::SAX::PurePerl, XML::LibXML::SAX, XML::SAX::Expat or something else depending on what was installed on the target machine. These parser modules are all written to the SAX API so you don't need to worry about which one you get.

On the other hand, if you'd prefer to access the XML contents as a DOM tree then once again XML::Parser would not be the best answer. XML::Parser's Tree interface is not really an object model and certainly not DOM compliant. XML::DOM uses XML::Parser to provide a DOM level 1 API but a better bet would be either XML::LibXML or XML::GDOME which provide DOM level 2 APIs (XPath and namespace support being the key bits you want). Whether you'd subclass these modules or simply use them is up to you.

You may find the Perl XML FAQ useful.