From: Christian Boos <cboos@...>
Date: 2001-11-16T23:31:40+09:00
Subject: [ruby-talk:25432] Why not xmlparser?  (was: Re: XML support in the standard lib;whatexactly?)


Hello everyone,

I may have missed something, but the original question that started the
previous thread was:

    "What kind of XML support should we provide in the standard Ruby
     distribution"

I don't see why 'xmlparser' is not perceived as the ideal candidate for
that task.

(xmlparser is authored by Yoshida Masato,
see http://www.yoshidam.net/Ruby.html#xmlparser)


I think that no one would seriously consider having "a pure ruby"
regular expression engine as the default regexp library.
We have regexp.c for that, and that's why Ruby is probably as fast as Perl
when performing text processing.

The same should hold for XML processing. The default implementation should
be a _native_ one, to be as fast as possible, because that's the only way to
go when one wants to handle multi-megabyte documents in a reasonable amount
of time.

I know this is not a trivial constraint. In a different context,
I had to compare the C++ implementation found in the Qt library against
expat 1.95, and the later was about 20 times faster!
So my guess is that if we would use expat (and therefore xmlparser)
XML processing in Ruby could be usable even for big documents.

Another advantage of using expat is that we would have a conformant XML
parser.

A practical advantage of bundling xmlparser with the ruby distribution
would be that it would ease the installation of xmlparser: currently, one
has to fetch and install expat first, then compile and install the xmlparser
extension. It would be much easier if expat would be bundled with ruby
itself, and be part of the default install.

Finally, I must add that I don't like XML event-based programming at all :)
What I like are cool APIs like REXML is!

So my dream would be to have the high-level API of REXML built on top of
the low-level (but fast) xmlparser...

-- Christian