Choosing a name for a product or software component that can stand the test of time is often difficult and can often be a source of confusion for users of the software if the its usage outgrows that implied by its name. I have examples from both my personal life and my professional life.

RSS Bandit

When I chose this name I never considered that there might one day be another popular syndication format (i.e. ATOM) which I'd end up supporting. Given that Blogger, Movable Type, and LiveJournal are going to provide ATOM feeds and utilize the ATOM API for weblog editing/management then it is a foregone conclusion that RSS Bandit will support ATOM the specifications are in slightly less flux which should be in the next few months.

One that happens the name "RSS Bandit" will be an anachronism given that RSS will no longer be the only format supported by the application. In fact, the name may become a handicap in the future once ATOM becomes popular because there is the implicit assumption that I support the "old" and "outdated" syndication format not the "shiny" and  "new" syndication format.


In version 1.0 of the .NET Framework we shipped three classes that acted as in-memory representations of an XML document

  1. XmlDocument - an implementation of the W3C Document Object Model (DOM) with a few .NET specific extensions [whose functionality eventually made it into later revisions of the spec]
  2. XmlDataDocument - a subclass of the XmlDocument which acts as an XML view of a DataSet
  3. XPathDocument - a read-only in-memory representation of an XML document which conforms to the XPath data model as opposed to the DOM data model upon which the XmlDocument is based. This class primarily existed as  a more performant data source for performing XSLT transformations and XPath queries

Going forward, various limitations of all of the above classes meant that we came up with a fourth class which we planned to introduce in Whidbey. After an internal review we decided that it would be two confusing to add yet another in-memory representation of an XML document to the mix and decided to instead improve on the ones we had. The XmlDataDocument is really a DataSet specific class so it doesn't really fall into this discussion. We were left with the XmlDocument and the XPathDocument. Various aspects of the XmlDocument made it unpalatable for a number of the plans we had in mind such as acting as a strongly typed XML data source and moving away from a tree based DOM model for interacting with XML.

Instead we decided to go forward with the XPathDocument and add a bunch of functionality to it such as adding the ability to bind it to a store and retrieved strongly typed values via integrated support for W3C XML Schema datatyping, change tracking and the write data to it using the XmlWriter.

The primary feedback we've gotten about the new improved XPathDocument from usability studies and WinFX reviews is that there is little chance that anyone who hasn't read our documentation would realize that the XPathDocument is the preferred in-memory representation of an XML document for certain scenarios and not the XmlDocument. In v1.0 we could argue that the class was only of interest to people doing advanced stuff with XPath (or XSLT which is significantly about XPath) but now the name doesn't jibe with its purpose as much. The same goes for the primary mechanism for interacting with the XPathDocument (i.e. the XPathNavigator) which should be the preffered mechanism for representing and passing data as XML in the .NET Framework going forward.

If only I had a time machine and could go back and rename the classes XmlDocument2 and XmlNavigator. :(


Wednesday, December 24, 2003 12:07:50 AM (GMT Standard Time, UTC+00:00)
I thought the name corresponds to the data model they are based. XmlDocument is based on DOM tree where stuffs like namespace prefix are important. XPathDocument is based on XPath data model where an attribute node is not a child of an element, but its parent is an element.

If it is true, then changing their name to XmlDocument2 will be confusing for me at least.
Wednesday, December 24, 2003 4:16:36 AM (GMT Standard Time, UTC+00:00)
Although the XPathDocument specifies what data model it uses in its name the XmlDocument does not if it did it'd be called DomDocument. More importantly besides XML language lawyers few people care about these distinctions and are more interested in the functionality the classes provide. At first glance, the name XPathDocument looks implies that the class should only be of interest to you if you want to do XPath which was incorrect in v1.0 and is a lot more incorrect today.

Wednesday, December 24, 2003 8:45:20 AM (GMT Standard Time, UTC+00:00)
Thanks Dare,
Yes I know people (including me) does not care about underlying data model. It is also true in Japan that XPathDocument is not famous as it deserves. It will be the very topic I will present at the conference held next year. I should work with XPathDocument2 and friends more...
Fumiaki Yoshimatsu
Wednesday, December 24, 2003 9:06:59 AM (GMT Standard Time, UTC+00:00)
Yeah, XmlDocument must be DOMDocument as it was in MSXML and XPathDocument must be XmlDocument!
Anyway, I believe XPathDocument name is good enough. At least it's stable and <s>well</s> known. So you guys should make it effective and easy to use and then evangelize it, evangelize it, evangelize it.
btw, what about making XPathNode public?
Also selection could be made easier somehow (SelectNodes/SelectSingleNodes are killers).
Friday, December 26, 2003 6:51:59 AM (GMT Standard Time, UTC+00:00)
Seems like there is a pretty good upgrade for the "RSS Bandit" name - change it to "Blog Bandit". It even sounds pretty good, and has a cool acronym (BB).
Comments are closed.