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
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, was quickly shaped into a useful specification. The first incarnation, called ...