From: "James Britt (rubydev)" <james / rubyxml.com>
> > Secondly, the DOM implementation is meant to be provided by the
execution
> > environment, so a pure-Ruby DOM implementation is not that important.
> > Rather, standard Ruby bindings to the DOM should be defined, that can be
> > implemented by the Ruby runtime for the application server.
>
> Again, I don't follow. In what way is "the DOM implementation [...] meant
to be provided by the execution environment"?  Are you
> saying it should be an OS library call?  Why isn't the same true of a SAX
parser?

The DOM is meant to provide a standard API to a document object model that
is being manipulated by scripts written in different languages.  E.g. a
single XHTML document can include scripts written in different languages.
It just happens that the only languages that are used in practice are
JavaScript and VBScript, but Tcl is also used in research browsers, and we
can dream that every browser will support Ruby eventually :-)  All those
scripts manipulate the document through the DOM API, but the DOM API is not
*implemented* in those languages.  It is implemented by the browser and
*exposed* to those languages.  This has the effect that the DOM API is
pretty much as bad as you can imagine in any language, because it is
purposefully lowest common denominator.  This is the reason that people put
up with a dreadful language like JavaScript for their web scripting when
there are so many better languages around.

Now, if your script is not running in a hosted environment, such as a web
browser, there is no real need for a cross-language document API, and there
are many good reasons not to have an API that purposefully ignores all the
good features of the language.  Factor in the fact that the DOM API does not
support XPath queries, or XSLT transformation rules, and you have a good
argument to avoid the DOM API and instead provide a standard Ruby XML API
that is more convenient for querying, modifying and transforming XML
documents.  If there is a great enough improvement in productivity (and
XPath and XSLT are enough in themselves), the "pain" of not using the DOM
will be more than offset by the pleasure given by the new API.

Why is this not the case for the SAX API?  Because SAX events are not
exposed to scripting languages by the browser.  A SAX parser passes events
to an application, which interprets those events to build an appropriate
runtime representation of the document (the GoF Builder pattern).  In a
browser with scripts, that's a DOM tree.  In an XSLT transformation engine,
that's a table-driven rule interpreter.  Etc. etc.

Cheers,
            Nat.