Re: Picking an XML Module

[vek]

Just out of curiosity, what limitations with XML::Parser are you referring to?

In the past, you'd probably hear a lot of people trying to steer you away from XML::Parser in favor of an 'actively maintained' module. Well, matts has picked up the XML::Parser reigns and released 2.32 and 2.33 just last week in fact. So you can now add XML::Parser back onto the 'actively maintained XML parsing modules' list :-)

In the past I actively used XML::Parser until the requirements for my project changed. I needed to be able to validate the XML against a DTD so I switched to XML::LibXML. I would have probably stayed with XML::Parser otherwise.

-- vek --

[mirod]

The main limitation of XML::Parser is that it is a low level module: you have to do a lot of work yourself. The best example is probably that you have to buffer the data returned by the character handler, or it will come in several chunks. In general SAX-level handlers are quite a pain to write. And XML::Parser is not even SAX, so you don't get to benefit from the work that is being done at the moment on SAX modules (XML::SAX::Machines or XML::Filter::Dispatcher for example have some very good ideas). OTOH I must sau that antiquated as it is, XML::PArser's interface is a bit more convenient that pure SAX.

But if I compare this to the simplicity of... XML::Simple (which would not work in this case, it does not deal well with mixed content), or to the power of XML::LibXML's XPath engine, I don't think that XML::Parser is a good choice today.

There are also some problems with the way XML::Parser deals with entities (especially in attribute values) that can be annoying if your XML uses them.

[vek]

mirod++, nice explanation.

-- vek --

[Matts]

I'm only maintaining XML::Parser so that it can ultimately be deprecated (and so that what bugs there are get fixed). Next release will have a LARGE warning in the documentation about how you shouldn't use this module.