In many places, entities are returned as org.w3c.dom.Elements. For example, in WebXml.getFilter(). It is nice to be able to return something that is-a Element (since it is an interface), but also supports additional java style property accessors. So, instead of returning an Element, it could return a class that implements Element, but also supports something like 'getFilterName' 'setFilterType', etc. This preseves compatibility with clients that want to do DOM type things, but provides an easier interface for code that wants to interrogate / manipulate the state itself. AbstractElement / Node are base classes for wrapping the dom objects, proxying the Element interface calls. In addition, it provides a getElementId() method - this is intended for subclasses to override and return some kind of identifier, that can be used to distinguish the element. For example, for a JNDI entry it might be the bound JNDI name. This can be used by processes (merge) that need to identify things that are the same in 2 different descriptors. One slight trouble is that due to the way the DOM has been extended (I'm baffled as to why it's been done this way), the 1.5 methods must be declared but can't be proxied (otherwise it won't compile correctly) - introspection could be used, but I'm assuming for now we don't want to use DOM level 3 functionality anyway..