> DOM is really designed to support scripts that are written to manipulate an
> XML or HTML document in many different environments, in which case the DOM
> implementation will be provided by the environment. E.g. an environment
> might be a browser, or an ASP-like server.

I'm not sure I understand your point.  While some scriptable applications provide a DOM API, the API itself not specifically
targeted for particular applications. It is a way to define a "learn once, use anywhere" API, wherever that may be.  And when you
say "environment", wouldn't that include a programming language?

>
> This raises some issues.
>
> Firstly, I don't think that this is the kind of environment in which most
> people are currently using Ruby to manipulate XML or HTML, so a Ruby-esque
> interface to XML would be more useful than a DOM interface.  It would be
> nice if IE, Mozilla, ISS, etc. supported Ruby in the future, but we can
> cross that bridge when we come to it.

Well, using Ruby Win32 you *can* script the MSXML DOM object.  You can write RubyScript Active Server Pages today (though I don't
know how stable it is).

Saying people don't use a DOM API in Ruby, so there's no immediate need, seems to be begging the question.  Now, if Ruby *came* with
a DOM object, and no one used it, that would be different.


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

>
> Finally, if a Ruby-eque API for XML processing was significantly more
> convenient than a DOM or DOM+XPath API in other languages, it would be a
> good selling point for the Ruby language and would encourage people to give
> it a try.

Yes.  But to tell people new to Ruby that they can't carry over their XML DOM experience because Ruby doesn't provide one is not a
selling point.


>
> So, my opinion is that a DOM implementation is not as high a priority for
> Ruby as a streaming parser, such as SAX.

I agree that SAX is more important than DOM.  But to dismiss the DOM API resupposes the intended audience of XML in Ruby.  If we
want to primarily target hackers who are glad to use whatever API  a language provides (because, say, they'll just write their own
parser on top of that anyway), then the DOM is non-critical.  If we want to lure XML-ites over to Ruby, with the idea that not only
can they reuse their XML experience, but get other treats aong the way, then DOM should be considered.

James

>
> Cheers,
>             Nat.
>