Sponsored Link •
Bill Venners: What were your design goals when you started XOM?
Elliotte Rusty Harold: More than anything else, I was looking for an XML API that novices—people who were not XML experts—could learn to use quickly, effectively, and correctly. I wanted an API that would not allow them to make mistakes, that would point them in the right direction. I wanted to make the right thing very easy to do, and the wrong thing difficult or impossible to do.
Bill Venners: What design principles did you want to keep in mind?
Elliotte Rusty Harold: The main design principle, I think, was simplicity.
I wanted maximum
simplicity consistent with correctness, to make the API as easy to
learn and use as it could possibly be. Keeping with that, one very important
thing is the principle of least surprise. It should always be very obvious what a
method does. And in reverse, you should be able to immediately guess what
the method is. If you need to create an element, the most obvious thing is, "Hey,
Element constructor. You pass in a
String that contains the name of the element."
At the same time, you don't want to eliminate the truly surprising parts of XML. You don't want to make the API simpler than XML itself is, which is a flaw I've seen in other APIs that have not achieved broad adoption.
Bill Venners: Such as, ElectricXML?
Elliotte Rusty Harold: ElectricXML is the big candidate. They have a reputation for being very easy to use, but I think that's because they have modeled something that is actually simpler than XML really is. They have smoothed over and cut away a lot of the rough spots of XML.
Also in keeping with the principle of least surprise, I intended to use Java idioms where they seemed appropriate, but not where they didn't. I learned from JDOM that you can go a little too far in that direction. Also, I was very unhappy with the large number of convenience methods in JDOM. That led me to decide I was not going to have convenience methods that made the overall design less convenient, less simple, less clear. I was going to make sure you could do anything you needed to do reasonably simply, but I wasn't going to give you three different ways to do the same thing.
I also thought it was important to start as small as I could, to model just XML and not try to do everything, at least not in version 1.0.
Bill Venners: Define everything.
Elliotte Rusty Harold: The minimal thing to do is XML plus namespaces. Everything would include XPath, XSLT, Catalogs, XInclude, XQuery, etc., a lot of additional work in the XML space that's not part of XML. To be honest, I haven't really satisfied that one. Several of those things have made it into XOM in recent months. They weren't there in the first version I announced to the XML Users Group, but a few of them are there now. To some extent I deliberately segregated them off into separate packages, so if you don't need XInclude, just ignore the XInclude package. And the dependencies between packages are one way. The XInclude package depends on the core package, but the core package doesn't depend on XInclude. Same story for the XSLT package.