From: ser@... (Sean Russell) Date: 2003-06-26T23:56:05+09:00 Subject: [OT] Re: REXML and double, rather than single quotes Ian Macdonald wrote in message news:<20030624010502.GH7020@caliban.org>... > > FYI, the application is not XML conformant if it doesn't accept single > > quotes around attributes. > > Yes, I know. I couldn't believe it when I finally discovered why my > files weren't being accepted. If I may digress, I'd like to re-make on observation about software developers. When I first started REXML, I just wanted an easier API for accessing XML. I wasn't particularly interested in full conformance, and at the time I was only intending to support a small subset of XPath. After the initial development, I was spending more time using REXML than working on it, but as more people used REXML, I received an increasing number non-conformance bug reports. Eventually, it became fully conformant with full XPath support. Now all I have to worry about is XPath 2.0. ;-) I think a lot of projects linger in that limbo of supporting enough features that the original developer doesn't have any interest in expanding the project, and being "complete" (whatever that means). The difference is that critical mass of complimentary users, who are enthusiastic about the project. I've been lucky enough to have a few users who even submit bug fixes, which in no small part contributes to my continued interest in working on REXML. I don't think a lot of people understand what a difference receiving patches makes; it sort of makes you feel more obligated to work on the project, since other people are. As a result, I want to thank everybody who's submitted patches, bug reports, suggestions, and messages of encouragement to REXML. In any case, there was another point I wanted to make: as I spend more time working on REXML, I find that I increasingly have to resist making changes that would make REXML less intuitive. I suspect that this is because XML itself has some features that tend to influence implementations; Namespaces is the biggest culprit. Namespaces are inherantly complex, and they complexify the API. There's the "correct" way to do them, that reflects how Namespace support is defined in the specification, and then there's the intuitive, programmatically easy way. Unfortunately, if you do them the correct way, the XML API immediately becomes obtuse to casual XML users. If you don't, then it is very difficult to have them behave as an XML expert would expect. For example, take the following pseudo-code: a = Element.new( "a", "some namespace" ) # create in namespace "some namespace" b = a.add_element( "b" ) What namespace is "b" in? Is "some namespace" the default namespace for "a" and its children? No matter how you solve this problem, the result is an API that is tedious to use. I'm still struggling with this, and probably will be, until XML is replaced by something else. The result is that it is *critical* to me to have users that offer API suggestions, even if most are rejected. Sure, I want to keep things easy, but you get to close to the code, and you start thinking about the problem from the wrong point of view... and you end up writing some monstrosity like DOM. This is the single greatest hazard to specifications: authors who don't to use their own creations, who think of the problem only from a design standpoint. For this reason I love Ruby, which has somehow maintained its simplicity. I'd be willing to bet that Matz writes as much code *in* Ruby, as he does *for* Ruby. Either that, or he has an inordinate amount of self-control to keep looking at Ruby from a user's point of view, rather than a developer's point of view. [This message was posted from a tool that has no spell checker. Sorry.] --- SER