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]
