[ANN] new aXSL interface for FO Tree

[Victor Mote <vi...@outfitr.com>]

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
week.
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:
http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-fotree/src/java/org/axs
l/fotree/

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

Re: [ANN] new aXSL interface for FO Tree

[Simon Pepping <sp...@leverkruid.nl>]

On Wed, Sep 07, 2005 at 08:33:52AM -0600, Victor Mote wrote:
> 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?

My choice of the word editor was not very good. I am actually thinking
of word processors or typesetting systems that request layout and
rendering services. They can do that by firing SAX events for the fo
objects that they construct to represent their layout request. But
they can also build the FO tree, if the application has a clear
interface for it.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: [ANN] new aXSL interface for FO Tree

[Victor Mote <vi...@outfitr.com>]

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:
http://www.foray.org/project/goals.html#big

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.

Re: [ANN] new aXSL interface for FO Tree

[Simon Pepping <sp...@leverkruid.nl>]

Victor,

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

Simon

On Sat, Sep 03, 2005 at 04:45:33PM -0600, Victor Mote wrote:
> 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
> week.
> 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:
> http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-fotree/src/java/org/axs
> l/fotree/
> 
> 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
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl