Yukihiro Matsumoto wrote:
|I was waiting for them to finish this API to begin working on it.  My only issue now is which XML library to use, because its then going to be a
requirement.

  |
  |1) NQXML
  |2) REXML
  |3) XMLParser (expat)
  |
  |Thoughts on this?

  The request for Ruby to handle XML out of the box has been asked for
  long time.  Once consensus (or merger) made, I'd like to include it in
  the standard distribution.

                                                          matz.

IMHO:

I was very excited and enthusiastic about Ruby+XML, but now I'm disappointed and frustrated.
(I'll rant a little(please don't take it personally; it's about technology, not people), but below, I'll offer visions and
solutions)

I don't know of any XML implementations in Ruby. Nr.3) is not implemented in Ruby. Nr.1) can only read a subset of english (AFAICS, NCRs like
é are not handled), and in many cases,  its' output can not be read by any XML tool. It can be used for working with a very limited subset of
XML, as the name implies. ("Not Quite XML"); there is no plan to make it an XML implementation. A short while ago, Nr. 2) was no XML
implementation; I don't know about the current state, or if it's planned to turn it into one. One of the main features of XML is interoperability. This is ensured

by the spec, which requires tight conformance. Conformance with the XML spec is no esoteric hairsplitting, it's the main requirement and the basic
feature of any implementation. It's not about some missing features, it's about interoperability (well-formedness, UTF-8, etc), which is the main reason to
use XML.

I tried to generate SVG with NQXML; the generated output is no XML, thus can not be parsed by any SVG viewer. (workarounds are nof un)
I tried to include data from an RSS feed; as soon as an NCR like é occurs in the RSS, NQ generates no more output. (can that be true? I hope
it's my mistake)
I wrote pages of problem reports, to hear that NQ will never be a conforming XML implementation.
There is no such thing as a non-conforming XML implementation. Either it's XML, or not.

I very much welcome the efforts that went ito those implemetations, they allow to play with Ruby
and XMLlike thingies, experiment with DOMLike APIs, and are useful for a certain set of tasks;
but I would not suggest to deploy them in any professional project, that might need to fulfill requirements not known at the beginning, but can be expected from
any XML tool.
Now it's time to provide Ruby with industrial strength XML libs.

Ruby + XML would be great fun. OO and XML are two of the most fascinating concepts of theses days.
XML in the standard lib of Ruby is very important for the widespread adoption of Ruby for professional XML solutions.
O'Reilly will publish two books, Java+XML and Python+XML; a title Ruby+XML currently sadly is impossible.

To get an XML treeparser in Ruby, plus DOM and DOM like APIs, XML writers and more, I suggest to form something like a special interest group,
with invited XML implementation experts from the Java (xml.apache.org, Python, Perl, etc) world(s).
Full XML implementations exist for example in Java. XML savvy Ruby wizards (I'm still anewbie :( ) could translate their source to Ruby; voila, some candidates
for the
standard lib.
Xalan, Xerces, Saxon, ...

-> XMLSIG: => standard lib: first:
treeparser, SAXparser, DOMAPI, DOMLikeAPIs/APIextensions, writers: XML, XHTML, etc;
then:
transformers: XSLT, validators, etc

I'm sure there are many other possible strategies.

Tobi