On 26.06.2003 21:48:10 Victor Mote wrote:
> > Then you mean reuse in the context of producing multiple output formats
> > in one renderung run?
> 
> Yes. Even if we think we don't want that now, we should have the flexibility
> to add it later.

Granted. I thought about that myself. I don't see why my API proposal
couldn't be enhanced (later), for example, with a MultipleFOPResult that
contains/holds a list of FOPResults. That would be a
backwards-compatible and even quite intuitive (See GoF Composite) way to
handle the case.

> Except for Avalonization (which I admit I don't understand, but which I
> understood not to be a factor here), I don't see what functionality your
> model provides over mine. On the Avalonization issue, I guess the easy way
> to get to the heart of the matter is to simply ask whether Avalonization can
> be implemented with the model I have proposed or not.

I can't answer that because I have the impression that your proposal is
incomplete. What I'm missing:
- How to specify output properties like encryption parameters
- How to handle Java2D?
- How to handle SAX input?
- How to handle FOP configuration?

On the other side, it doesn't matter so much. I think it is important to
separate the inner glue from the client interface, so to isolate FOP's
Avalon container (or whatever we will use/do) from its environment so
FOP provides a blackbox interface to the outside. Only in the
Cocoon-context should there be a possibility to pass in a parent
ServiceManager so FOP can use Cocoon's SourceResolver, parser factories
etc. Your proposal can probably be made to handle that.

> I did have one afterthought that I think I should mention. The JAXP thing
> caught me a bit off-guard, and I only just now sorted out in my mind why. I
> don't use these tools often enough or in enough detail to keep this fresh in
> my mind (but I think I have the concepts straight), so please correct me if
> I am wrong. If I want to use Xalan, for example, I could use a Xalan
> interface, or I could use a Xalan implementation of the JAXP interface.

The problem with this example is that I can't think of any reason why I
would need a Xalan-specific API (if there is still one). Xalan-1 had a
proprietary one. That got deprecated with the arrival of TraX/JAXP. But
my statement is not really based on extensive research. Maybe there ARE
use cases.

> You
> mentioned in an earlier posting that the functionality between the two
> didn't necessarily need to match up.

Right, but it should be avoided to have two different client APIs
because you will have to maintain and more importantly support them.

> This implies (and makes sense when you
> think about interfaces) that it is a lowest-common-denominator.

Yes, but holding that open for extensions:
- Ability to add new subclasses of FOPResult which only certain
  implementations support.
- Ability to pass in special output property objects to control special
  features.

> There may be
> times when, to get the full richness of an implementation, you have to use
> things that are specific to it because the higher-level interface couldn't
> and shouldn't force all implementations to implement that feature. FOP and
> RenderX might (and probably already have) evolve(d) to meet different
> use-cases. So it makes sense to me to use a simple lightweight API for FOP
> (if possible), and if we want to build an industry-standard API like that
> which you have proposed, that it be done in a separate project or at least
> package, and probably be done in concurrence with the other implementors.

You're right again. But then it happens that a good API gets adopted by
other parties. At any rate I'll gladly participate in formulating a
standard API as a separate project as my time allows it.

RenderX guys: If you're listening in, I'd like to hear your thoughts
about having/creating a common client API for XSL-FO processing in Java.

> That would be my preference, but I do not feel strongly enough about it to
> do much more than mention it. I think this distinction probably also
> explains the different wavelengths that we seem to be on.

The biggest difference probably arises from your focus on the inner glue
and my focus on the client API. Your thoughts are very valuable but they
should evolve in the context of the inner glue because that's where you
invested most of your brain time, I guess.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to