From: Alan Chen Date: 2001-11-17T00:50:21+09:00 Subject: [ruby-talk:25455] Re: XML support in the standard lib;whatexactly? On Fri, Nov 16, 2001 at 08:45:26PM +0900, Nat Pryce wrote: > 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. If you're writing a library on top of a standard interface, why would the library force the user to employ the lower level interface and the library interface? Multiple XML libraries hasn't seemed to hurt perl. > 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. I think that the DOM API should also be included for sake of completeness and interoperability. It is the library implementor's descision what API to base thier capability upon. That decision generally won't be made in a vacuum, if they implementor is on ruby-talk, I'd likely reccommend the ruby-way API. But having the DOM API available would make it easier to port many existing XML libraries over to Ruby. -- Alan Chen Digikata LLC alan@digikata.com http://digikata.com