The W3C XML DOM, as specified by the org.w3c.dom package, contains a egregious design error. In an XML element node, not only are there pointers to the child nodes but the child nodes point back to the parent. These "back-pointers" are a regular design mistake made by inexperienced programmers and, sadly, repeated by the experienced programmers in W3C.
The problem, in essence, is that these pointers prohibit sharing of child elements between parents. It means that the simple recursive programming style employed when transforming tree-like (i.e. recursive) data structures becomes cumbersome or impossible. In addition the prohibition against sharing means that both compactness and speed are seriously compromised.
The normal recursive style constructs trees from the bottom-up. The interface specified by org.w3c.dom more or less requires that XML trees are build from the top-down. It is just about possible to overcome this limitation, with some very careful programming, but the lost performance and compactness cannot be recovered.
Of the two, a loss of compactness is the most serious. The org.w3c.dom interface implies (approximately) a factor of 2 times bloat over the naive implementation used in MillScript.
The MillScript implementation would benefit from a more compact encoding of attributes, incidentally. At present attributes are stored in TreeMaps. This has the benefit of fast lookup - but is far too fat. I would have thought recoding the attributes as an array of alternating name/value entries would be a better tradeoff.
In the implementation of MillScript, it is always preferable to employ TreeMapWithDefault if those maps are ever to be exposed to a script-writer.
TreeMaps are based on the compareTo method of the Comparator interface and this does not require that all Objects are comparable - indeed the JVM freely raises ClassCastExceptions when comparing objects of different types. e.g.
"foo".compareTo( new Integer( 3 ) ); // throws ClassCastException
Since MillScript permits the script-writer to create hetrogenous Maps a plain TreeMap would be fundamentally inappropriate. The implementation of TreeMapWithDefault corrects this problem by supplying a hetrogeneous Comparator.
HashMaps do not suffer from this problem. Naturally it is slightly preferable to use HashMapWithDefault if script-writers will see the object, otherwise getDefault (and friends) will fail, but it is not necessary.