Lessons Learned

Place as much logic as possible in element classes.

XML and Java are good friends!

Avoid circular dependencies:
they hint a better design is around the corner.

Keep classes small, and packages modular.

Previous

Narrative

Put Logic in Element Classes

The xs, xu and da packages all implement their main functionality in their specialised element classes. This has several benefits:

Extra functionality can be added by writing new element classes and registering them. In the case of the XSL engine, once the infrastructure was in place, implementing each of the XSL elements (eg. 'empty', 'eval') is solely a matter of implementing element classes; no other part of the software is affected. Thus extensions to XSL can be added cleanly and easily.
It's very easy to locate the code that is responsible for a particular purpose.
Using 'put logic in element classes' as a guiding principal cuts the number of design decisions a developer has to make. This ought to (!) lead to fewer messy implementations.
The functionality outside the element classes is very small. Thus all the classes tend to be small (though there may be lots of them).

Further start-up processing can be invoked as required, provided the element classes required have been registered beforehand. Registering must currently be hard-coded, although it would be straightforward to define an element whose purpose is to register other elements and allow their use immediately. The xt application uses'DatabaseDriver' elements to load JDBC driver classes (although there appears to be a bug in the JDK - because they are not visible after start-up, although manually loading them in exactly the same way later does work).

XML and Java are Good Friends!

The dynamic nature of Java (primarily its ability to instantiate any class solely from its name) means software can be called about which the caller knows very little. This can be the basis of extremely expandable applications. This ability can be harnessed to XML in at least two ways:
The xs, xu and df packages all implement their main functionality in their specialised element classes. This has several benefits:

The classes used to handle different types of XML elements can be easily changed (as we have seen). Special processing for particular elements can be slotted in on the fly.
Class names can be placed in XML files, so new classes can be added without changes to the calling application. (Parameters can be obtained from XML files too.)

(There are security issues here, the solutions to which this margin is too narrow to contain.)

Avoid Circular Dependencies

It was originally very difficult to find a design for the XSL engine which avoided circular dependencies: rules contain actions, actions invoke rules. But determination to avoid a circular dependency here prompted a search for an alternative, which led to a neater solution: the introduction of a 'stylist' class to drive the processing. (It should be noted that the 'stylist' class is actually quite small and not complex.)

Keep Classes Small, and Packages Modular

These are, rather, lessons from OO/Java experience than anything to do with XML!