> 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.

It does look good.


> 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.


Exactly true.  I thought this was implied in the idea of being part of the base Ruby install.


> 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.

Tell me about it!  :)  I couldn't get expat properly installed and callable from xmlparser when I set up rubyxml.com.  (I'm not root
there, and don't have quite the sysadmin access I would really like ...)

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

I like REXML quite a bit, too, but having SAX is very handy for slurping huge documents that could never easily fit in memory.
From the xmlparser readme file it looks like it provides the familiar SAX callback methods (startElement,  endElement, character, an
so on.) which is nice.


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

Good plan.


James

>
> -- Christian
>