Simon Pepping wrote:

> I find this certainly interesting. IN principle, it would 
> allow client programs, say an editor, to construct its own 
> implementation of the FOTree interface.

Thanks for your interest. I had to think about your response for a bit. I
guess it depends on what kind of editor you are thinking of. The aXSL
interface is currently a read-only concept. IOW, the implementation will
create the tree, and users of the interface will only be able to extract
data from it. So you are perhaps thinking of something that edits upstream
of the FO Tree, perhaps editing the underlying semantic XML?

Now, the planned AreaTree interfaces will be in two parts, one for creating
the AreaTree, the other for using it (the same implementation can implement
both). I hadn't thought about the same thing for the FOTree, but it is an
interesting idea, and might be a hook toward solving the transformation
problem discussed here:

One other item of possible interest to you here is that the FOray
implementation (but not currently the aXSL interface) implements the
javax.swing.tree.TreeNode interface, which would I think be useful in an
*FOTree* editor or viewer[1]. Perhaps I should push that up to aXSL as well,
since it already has all of the tree-like concepts in place anyway and
doesn't really cost an implementation anything extra.

Victor Mote

[1] Disclaimer: I strongly dislike the idea of an FOTree editor.

Reply via email to