FWIW, I completed today the extraction of a set of interfaces for aXSL to
generically describe an FO Tree. The FOray FOTree implements these
interfaces, and the other FOray modules have been changed to use the aXSL
interfaces instead of the FOray FOTree implementation. The only dependency
within FOray on FOray FOTree now is one that handles creating a default
implementation if none is passed to FOraySession.

For some time now, the FOray FOTree has been available as an independent
module. This new set of interfaces theoretically allow non-FOray FOTree
implementations to be used within FOray. I realize that there is not a great
demand for this ATM. However, there are numerous immediate benefits:
1. It is now possible to more clearly "show" rather than merely "tell" the
"where" and "when" issues that I described in another thread earlier this
2. There is something about having to extract an interface that forces one
to address ugly design issues and get them cleaned up. I found and fixed a
few. There are probably still some others that will become apparent in a
closer review of the interfaces.
3. It opens the door to the possibility of comparing different FO Tree
implementations to each other with other components remaining fixed. I don't
know whether the FOP FO Tree can be adapted to implement this interface or
not, but I suspect that it can.

For any who are interested, the code can be conveniently viewed here:

The slightly bad news for Jeremias is that the outer-level FOray API has
changed to accommodate the new FOTreeServer that allows this pluggability.
However, this is easily fixed by passing one more "null" parameter in the
FOraySession constructor.

The interfaces are not well documented ATM and are no doubt weak in many
other ways as well. A great many of the interfaces are empty markers,
providing type identification only. There may be a better way to handle
this. Or it may turn out that additional methods will need to be added to
them to accommodate more sophisticated needs.

I hope this is of general interest to this list, and apologize if it is not.

Victor Mote

Reply via email to