From: Nat Pryce Date: 2001-11-15T11:05:31+09:00 Subject: [ruby-talk:25236] Re: XML support in the standard lib;whatexactly? From: "James Britt (rubydev)" > > 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.