Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)

I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Thursday July 19, 2001
03:25 AM

XML::Parser

[ #458 ]

I wish people would stop writing modules and code with XML::Parser.

PLEASE STOP IT! :-)

Seriously though, the problem is that XML::Parser isn't interoperable with anything, and it isn't replaceable with anything. Instead people should be using SAX.

Now I know there's a lot more out there about using XML::Parser, and not much about using SAX, but nobody is ever going to write a XML::Parser-like module for any other data source. Neither are they going to write an XML::Parser compatible interface for any other parser backend (like libxml2). It's just not going to happen, because despite XML::Parser being a parser factory, it is still very much tied to Expat. The callbacks recieve an Expat object, and the methods available on that object are expat related.

So, for those of you (and yes, I'm guilty too!) writing modules based on XML::Parser, stop and think about it before proceeding. SAX is a much better option. And your module can suddenly take advantage of being able to use Excel spreadsheets or CSV files as a datasource, and I'm sure more modules doing the SAX funky dance will come along soon.

Oh, and SAX is more flexible. For example you can chain SAX modules together. But if you want to see how to do that you're going to have to come to my AxKit talk (where I'll briefly talk about Perl and XML before diving into AxKit) at TPC.

Now I have to go and re-write DBIx::XML_RDB to generate SAX events, rather than XML. :-)