Perl and XML

Chapter 5. SAX

XML::Parser has done remarkably well as a multipurpose XML parser and stream generator, but it really isn’t the future of Perl and XML. The problem is that we don’t want one standard parser for all ends and purposes; we want to be able to choose from multiple parsers, each serving a different purpose. One parser might be written completely in Perl for portability, while another is accelerated with a core written in C. Or, you might want a parser that translates one format (such as a spreadsheet) into an XML stream. You simply can’t anticipate all the things a parser might be called on to do. Even XML::Parser, with its many options and multiple modes of operation, can’t please everybody. The future, then, is a multiplicity of parsers that cover any situation you encounter.

An environment with multiple parsers demands some level of consistency. If every parser had its own interface, developers would go mad. Learning one interface and being able to expect all parsers to comply to that is better than having to learn a hundred different ways to do the same thing. We need a standard interface between parsers and code: a universal plug that is flexible and reliable, free from the individual quirks of any particular parser.

The XML development world has settled on an event-driven interface called SAX. SAX evolved from discussions on the XML-DEV mailing list and, shepherded by David Megginson,^[1] was quickly shaped into a useful specification. The first incarnation, called ...