James Britt wrote:
> I don't think there have been *any* points *against* a "Ruby way" API;
some of the threads, though, seem to suggest that it would be
> the *only* API.

I've been in favour of Ruby supporting a "native" API and a DOM API, but
thinking about it, this may be a disadvantage for the standard library.  The
standard library is a foundation on which to build higher-level
functionality, including other libraries for performing XML processing.  If
there are two standard Ruby XML APIs, then an author of an XML library will
write to one of these APIs, and so users of the other API will not be able
to use that library in their applications.

Fragmentation of a low-level infrastructure libraries disadvantages the Ruby
userbase. As an example, look how the two Ruby unit test frameworks has been
a drawback to users of both Lapidary and RubyUnit.  Lapidary users have not
been able to use RubyUnit extensions such as Ruby/Mock, while RubyUnit users
have not been able to use the GUIs written for Lapidary.  This will be
sorted out now that Lapidary and RubyUnit are merging into a single
framework that will be part of the standard library.

So, my opinion is that the standard library should include a streaming
parser and a Rubyesque document API that includes XPath and XSLT, but that a
DOM API should be distributed separately from the standard library.

Cheers,
        Nat.