cvs commit: xml-fop build.xml

2003-06-28 Thread pbwest
pbwest 2003/06/28 18:02:22 Modified:.build.xml Log: Base all relevant properties on ${basedir}. Remove jimi libraries from dist.bin.lib fileset. Revision ChangesPath 1.85 +15 -16xml-fop/build.xml Index: build.xml

RE: Alternative API proposal (was: startup refactoring)

2003-06-28 Thread Victor Mote
J.Pietschmann wrote: > Victor Mote wrote: > > BTW, we'd better change the name of FOPResult if we're going to > try to sell > > this to a wider audience :-) > abbr for FormattingObjectsProcessingResult. No need to change :-) Just don't be surprised to see a counter-proposal RenderXResult, an ab

Re: Alternative API proposal (was: startup refactoring)

2003-06-28 Thread J.Pietschmann
Victor Mote wrote: BTW, we'd better change the name of FOPResult if we're going to try to sell this to a wider audience :-) abbr for FormattingObjectsProcessingResult. No need to change :-) J.Pietschmann - To unsubscribe, e-mail

RE: Alternative API proposal (was: startup refactoring)

2003-06-28 Thread Victor Mote
Jeremias Maerki wrote: > > 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

Re: lib/jimi in distribution

2003-06-28 Thread Jeremias Maerki
Looking at the CVS history, I believe it's a relic from the times where FOP had, cough, jimi.jar, cough, in CVS. On 28.06.2003 16:23:47 Peter B. West wrote: > Jeremias Maerki wrote: > > No, of course not. > > Well, ..er, ..um, no, of course. Supplementary question: was that entry > perhaps inte

Re: lib/jimi in distribution

2003-06-28 Thread Peter B. West
Jeremias Maerki wrote: No, of course not. Well, ..er, ..um, no, of course. Supplementary question: was that entry perhaps intended to be to be an exclude? Peter On 27.06.2003 06:36:17 Peter B. West wrote: I just noticed in the dist.bin.lib fileset of build.xml in HEAD. Is that supposed to b

Re: Xalan API was Re: Alternative API proposal

2003-06-28 Thread Jeremias Maerki
Ok, but that's a special purpose API that has (almost) nothing to do with XSL transformation. And it's only a proprietary API because there is no standard API for this. On 28.06.2003 13:23:21 J.Pietschmann wrote: > Jeremias Maerki wrote: > > The problem with this example is that I can't think of a

Xalan API was Re: Alternative API proposal

2003-06-28 Thread J.Pietschmann
Jeremias Maerki wrote: 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). Everytime you need something to do which is not in JAXP, like using an XPath to select nodes from a DOM. J.Pietschmann -

Re: Alternative API proposal (was: startup refactoring)

2003-06-28 Thread Jeremias Maerki
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 wh

Re: lib/jimi in distribution

2003-06-28 Thread Jeremias Maerki
No, of course not. On 27.06.2003 06:36:17 Peter B. West wrote: > I just noticed > > in the dist.bin.lib fileset of build.xml in HEAD. Is that supposed to be > there? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTEC