Re^2: Using the XML::Parser Module

I would agree with you that XML::LibXML is also a good choice. In my (oddly enough limited ;--) experience, it feels a little "lower-level" than XML::Twig, mostly because it forces you to use the DOM to process the data, while XML::Twig has (lots of!) higher-level methods. I agree that it implements very well quite a few standards, and it probably lends to more rigourous code than XML::Twig.

One word to correct you on one point: XML::Twig did not offer real XPath support: it does now, if you use XML::Twig::XPath, which simply re-uses XML::XPath engine.

Comment on Re^2: Using the XML::Parser Module

Replies are listed 'Best First'.
Re^3: Using the XML::Parser Module by Aristotle (Chancellor) on Nov 02, 2005 at 14:40 UTC
I always think of you and cringe a little when I recommend against your module. You did a really admirable job of building something actually usable onto XML::Parser, and for a long time XML::Twig was my indeed favourite. It’s just that expat and XML::Parser really needed that work to be turned into something sane, whereas XML::LibXML is sane to begin with. Sorry. `:-) :-(` Re: XPath support: thanks for the pointer; noted. Makeshifts last the longest.	[reply]
Re^4: Using the XML::Parser Module by mirod (Canon) on Nov 02, 2005 at 15:48 UTC
Agreed, I am not sure expat is that bad, but indeed XML::Parser is a royal pain to deal with, especially when trying to be compatible with various versions. If I had started writing XML::Twig a little later, I would probably would have written it using SAX, and I would have been able to change the parser. As it is, SAX was very new at the time, all other modules were built on top of XML::Parser, so I went with that, and then it got so entangled with XML::Parser's quirks that decoupling them would be real hard now. Oh, and don't feel bad advocating XML::LibXML, it is indeed a very fine module.	[reply]