Stephen Zander <[EMAIL PROTECTED]> writes:
> >>>>> "Ken" == Ken MacLeod <[EMAIL PROTECTED]> writes:
> Ken> A little background first. SAX modules come in three basic
> Ken> flavors, "drivers" which generate SAX events (parsers are
> Ken> drivers), "handlers" which consume SAX events (writers and
> Ken> tree builders are handlers), and "filters" which are both
> Ken> handlers and drivers.
>
> Do any of these have a standard API, e.g., is there a SAX driver API
> that all modules should provide?
Yes, these are standard APIs that are shared by many modules that
perform many completely different things using those standard APIs.
> If so I'd say reserve SAX::Driver, SAX::Handler & SAX::Filter & let
> any implementations live directly undex SAX::. The three reserved
> modules could just provide a standard import routine to an
> implementation in, like so
>
> use SAX::Handler 'SAX::My3LeethA|\|ld3r';
>
> in the same way the DBI modules abstractes the DBD::* modules.
Unlike DBI, the various modules are not intended to be generically
interchangeable, one module may filter out whitespace from XML events
while another module may build a tree of objects for other modules to
use. The module namespaces are a convenience for users to let them
know which of two, or both, APIs are being used: the driver API or the
handler API, together they make a filter API.
There are no modules (nor any reason I can think of to make such
modules) called SAX::Driver, SAX::Handler, or SAX::Filter.
For reference, note that the use of "driver" in this context means "a
module that generates SAX events", synonyms include parser, reader,
event generator, producer (as in producer/consumer), and source (as in
source, filter, and sink). This use of "driver" does not mean
"implement a standard API on different backends", as used in DBI.
> If not, then perhaps SAX::Driver*, SAX::Handler* etc in the same way
> that Apache modules are Apache::Auth* etc.
-- Ken
