TAKAHASHI Masayoshi <maki / rubycolor.org> wrote in message news:<20020208025017S.maki / rubycolor.org>...
> 
> In addition, creating objects need cost. Yes, this cost is
> not so expensive, and Ruby usually pays many many cost :-)

Well I guess I'd like to see this benchmarked. There's always going to
be a payoff between flexibility and speed. At the moment the Perl SAX2
parsers are several orders of magnitude slower at raw parsing speed
than pure XML::Parser is, but hopefully we can narrow down that
margin.

> By the way:
> I don't catch up with Perl-XML ML, but (maybe last year)
> I found discussion about ParserDetails.ini in Perl SAX2.
> I think Ruby also need similar configuration, but I don't
> know what conclution they come to.
> 
> Could you tell me how to use (or not use) ParserDetails.ini
> in Perl?  Is there a document about it?

The whole thing is still in a little bit of flux. Basically
ParserDetails.ini resides in the same directory as XML/SAX.pm, and
contains information about all installed parsers, such as whether they
support Namespaces and other features. When you use the factory method
to create a parser, it consults this file to see which parser to
return to the user depending on what features they asked for. It
basically works the same as the Java SAX factory stuff.

The problem is it doesn't work too well for local module installations
- i.e. I'm a user and I don't have root on a box, and want to install
XML::SAX::FooParser, but I can't write to ParserDetails.ini. We need
to work on that still.

The docs are all in the XML::SAX distribution, which you can read
online at http://search.cpan.org/ (use the search box)

Matt.