Hi Victor

On 27.11.2004 16:53:54 Victor Mote wrote:
> I looked at the doc, and I think this is all pretty useful. I'd like to
> spend some more time on it later, and I think I will probably write a FOray
> implementation after I get 0.2 released. Here are some preliminary thoughts:

I finally downloaded the Foray code yesterday because I thought it might
be fun to write that implementation already. I didn't invest a lot of
time but I got confused about the mixture of Foray and FOP code. Didn't
really know where to start. But that's another story. I should probably
look harder. Anyway, I got a renewed itch now to look at the PS
interpreter. :-)

> 1. How do you anticipate deploying this? It looks like the user is aware of
> which implementation he is using, and therefore knows or can find the
> class(es) that implement the interface(s). So it looks like your org.xml.fo
> & org.xml.fo.helper stuff would go in some vendor-neutral project, and the
> implementations would simply be part of the vendor package. Does that sound
> right?

Exactly. That's where the whole thing is slightly different to JAXP. I
want to have multiple implementations at the same time and I want to
control which.

Either you set up the classpath yourself and instantiate the right
FOProcessorFactory or you use the XML package format to load an
implementation dynamically along with additional libraries (Barcode4J
comes to mind) and use that.

> 2. One thing that I really like about your idea is that, if done properly,
> the implementation classes almost become self-documenting tutorials on the
> API for the specific implementation. If jafop exposes a general API for what
> is needed to process an FO document, then the innards of the implementation
> show how to use the API for the specific implementation.

Right. :-) That one didn't occur to me.

> 3. There is more going on here than I anticipated. In org.xml.fo, there are
> four interfaces that a vendor needs to implement. I am not sure what
> FOPEventListener is supposed to do. Of the other three, it looks like two of
> them exist to handle variations in input. I *think* that these could be
> boiled down to just one interface, and that the input variations could be
> handled with overloaded methods or some other way. However, I sure could be
> missing something.

FOPEventListener is an unfinished idea to get information on things
happening inside an FO processor. Examples: Overflow warnings, Missing
images, new pages etc. Nothing's implemented in this direction, yet.

FOProcessor (equivalent to JAXP Transformer) represents the actual FO
processor even if the implementation isn't implemented that way.
Actually, I routed the implementation of the process() method through
the Handler. The main idea is to establish the same structure known from
JAXP. I'm aware that the FOProcessor.process() method will probably
never be used except for trivial examples not involving XSLT.

The FOProcessorHandler is the real work horse IMO. It's used to bind
XSLT output to FO input through SAX events.

The Factory interface is simply responsible to instantiate the
FOProcessor(Handler) implementations.

It's probably best if I just publish the sources so things become
clearer. Will do that later today.

> 4. If you think aXSL is an appropriate home for the vendor-neutral pieces of
> this, that would make some sense to me. As we have previously discussed,
> jafop is a subset of what aXSL is supposed to eventually handle. Vendors
> using the "app" or "jafop" or whatever part of aXSL would be free to ignore
> the other parts of it, if and when they appear.

The problem with aXSL I've got WRT JAFOP is that it would IMO create
confusion between stuff for FO implementation developers and FO users.
Another point: Sun donated JAXP to the ASF. So the ASF may not be a bad
place after all, as long it's not directly within the FOP source code.
JAXP, Xerces-J and Xalan-J are all in different locations.

> 5. I know when I see the substring "FOP" in the vendor-neutral part of this
> stuff, that it is being used in a vendor-neutral way. However, since the
> general term "FO Processor" has already been taken by a specific
> implementation, it may be good to find some variation, not only for
> political reasons, but practical as well (cuts down on confusion). Maybe
> something as simple as PFO, or maybe the aXSL name can help here.

That's been bothering me, too. It's also the reason why I mentioned that
the naming can change. :-) I'd also prefer something a little farther
from "FOP" but nothing really good has occured to me, yet. Good ideas
always welcome. Something with "XSL" in the name seems problematic to me
because I often run into people who can't distinguish XSL, XSLT and
XSL-FO. Staying near "FO" would help avoid any confusion.

> I think you have done a good thing here.

Thanks. We'll see what comes out of it.

Jeremias Maerki

Reply via email to