Exceptions. (Was: AreaFactory patch)

[Finn Bock <bc...@worldonline.dk>]

[Peter]

> On the topic of exceptions, and now that it's all over...
> 
> I was puzzled by this discussion.  Would anyone expect that Defoe would 
> subclass SAXException for document validation errors?

That is your choice. Surely exceptions that occured during SAX event 
handling (eg startElement) should be handled, either by wrapping the 
exception in a SAXException, or by passing SAXExeption subclasses along 
or by throwing some kind of RuntimeException (did I miss another 
option?). I don't think exception handling by
     e.printStackTrace();
is a long term solution.

> If not (it doesn't), why not?  

AFAIK, there is no well defined API to XSL:FO parsing, so everybody will 
do it differently.

> And if someone was inclined to write an FO processor 
> using a DOM front-end, would you expect validation errors to throw 
> subclasses of SAXException?  

Ofcourse not.

> The same fo file, with the same errors, 
> could be processed by three different processors, using three different 
> parsing methodologies, and the same validation errors would encountered.

Do you mean that the 3 different processors should ideally report the 
same validation errors in the same manner? That can only happen after 
someone standardize a SAFO API (Simple API for FO parsing). Until then 
all implementation will throw different exceptions, which is fine by me.

> (OK, you can classify at least two categories of validation error, but I 
> think the argument still applies.)
> 
> SAX != XML parsing, let alone document validation.

True, but FOP heavily depends on SAX.

regards,
finn

RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

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

Jeremias Maerki wrote:

> Ah, now I'm starting to see where this is going. I think this 
> something extremely difficult to do. To a certain degree it 

Agreed.

> sounds like my ideas/plans for the XML Graphics project, 
> namely to separate certain peripheral components (fonts, PDF 
> lib, Graphics2D implementations etc.) from FOP so efforts can 
> be pooled between projects where easily possible (i.e. 
> without major religious wars). For example, Peter is quite 
> interested in the Graphics2D implementations. But going to a 
> level of detail you hint at (at least that's my impression) 
> will prove really difficult. You know I'm all for 
> componentization, but you may have too high hopes here. But I 
> could be wrong. Don't spend too much time explaining this to 
> me. :-) We'll just see what happens. I will monitor what's 

The "standards" themselves do not need to be monolithic. So maybe one
implementation implements only aXSL-Font (I'm making this up as I go), while
another might implement all of them.

The idea is that one more axis of benefit is added into the product mix.
Assume that modularization is even possible, which is yet to be proved, at
least by any of the open-source implementations of which I am aware. Assume
also that, all other things being equal, it is a desirable trait, not just
for the developer, but for the end user. If these are both true (and I think
they are), a product that chooses *not* to implement it would presumably
want to have a really good reason for not doing so. Defoe's reason might be
superior performance (as I understand it), which is quite possible, and
FOP's might be a quicker time-to-market (as I understand it), also quite
possible, at least starting from today.

If *setting* a standard devolves into a religious war, we should probably
abandon the effort. However, I don't know that it needs to. When you think
about it an API for the FOTree, for example, the standard almost writes it
for you.

> going on. So, we're still going in the same general direction 
> although I'm still a bit concerned that you based your PDF 
> part on the maintenance branch code (that's still the case, 
> isn't it?).

FOrayPDF is based on the maintenance branch code, but I am not sure I
understand your point. I assume you are thinking of how to get a PDF-library
created in the new Graphics project? If I understand where you are headed,
you have to either duplicate in HEAD the work that I have done in isolating
it, or you have to duplicate the changes made since FOP forked itself. Since
it is in FOray's interest to have the better PDF library available, I might
do the latter -- it is just a matter of priorities & right now finishing the
modularization is more important (to me). And since PDF is a relatively
discrete part of the system, it may not be too hard to do. If you guys
decide to do the former, having the aXSL APIs in place would be a very
valuable tool in that process. I'll be glad to explain why when you are
ready to look at it, and perhaps I'll have something concrete (about the
abstractions :-) to show you by then as well. I'll be very happy to try to
coordinate this stuff so that we don't duplicate effort -- there has been
and will be too much of that as it is.

Victor Mote

Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

[Jeremias Maerki <de...@greenmail.ch>]

Ah, now I'm starting to see where this is going. I think this something
extremely difficult to do. To a certain degree it sounds like my
ideas/plans for the XML Graphics project, namely to separate certain
peripheral components (fonts, PDF lib, Graphics2D implementations etc.)
from FOP so efforts can be pooled between projects where easily possible
(i.e. without major religious wars). For example, Peter is quite
interested in the Graphics2D implementations. But going to a level of
detail you hint at (at least that's my impression) will prove really
difficult. You know I'm all for componentization, but you may have too
high hopes here. But I could be wrong. Don't spend too much time
explaining this to me. :-) We'll just see what happens. I will monitor
what's going on. So, we're still going in the same general direction
although I'm still a bit concerned that you based your PDF part on the
maintenance branch code (that's still the case, isn't it?).

Concerning the common end-user API, I'll publish my findings as soon as
they are somewhat "presentable".



Jeremias Maerki

RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

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

Jeremias Maerki wrote:

> from the website I don't quite get the scope of the project. 
> That might have to be made clearer. Anyway, I didn't want to 

Yes, just as soon as it is totally clear to me :-) Right now, it boils down
to "here are some things that I think could/should be shared, can anybody
think of anything else?"

> talk about it just yet, because it's not ready, but recently 
> I started writing a JAXP-like API for XSL-FO processors (I 
> called in JAFOP for now). It basically implements the ideas 
> we came up with in the API discussion over a year ago. In the 
> next few months I will probably need to integrate several 
> different FO-processors and want to have a common API for all.
> Especially having a uniform API between FOP maintenance 
> branch and HEAD is important to me because I need to get FOP 
> 0.20.5 set up for PDF output and I will most probably need 
> the RTF output of FOP HEAD quite soon (all in the same VM, of 
> course). Also, the fact that we got 4 OS-FO-processors 
> screams for a common API so they can be used interchangeably.

I think you are thinking API for the application as a whole. My vision for
aXSL goes quite a bit deeper than that, trying to get a common API for the
modules, IOW breaking the problem down into smaller pieces. My perfect world
right now would have me using FOrayFont with RenderX. (That is not to say
that FOrayFont is as good as RenderX's font handling -- it is not, yet
anyway. But it means that I can get where I need to go more quickly with
FOrayFont than I can with RenderX). Even if RenderX didn't subscribe to
aXSL, making FOray do so would seem to make it more usable to more people.
And it at least gives hope to someone writing a piece that it might be
pluggable with some other pieces.

There was a thread several weeks ago that had to do with how to standardize
extensions between the various applications, and Finn's work on Property
binding was an indirect influence here as well. However, the main thing that
started me down this path was thinking through the possibility of further
modularization within FOray. Right now, for example, FOrayFont is totally
independent of anything that looks like XSL-FO processing. But FOrayPDF is
highly dependent on FOrayFont as are layout, the renderers, etc. It seemed
like a desirable thing to pull out a layer of abstraction that lets FOrayPDF
work, for example, with any other conformant Font system, or vice versa.
Now, fonts and graphics are pretty easy. I can pull out an abstraction for
fonts that has three interfaces, one of which is already written (it may
need to get more complex later), and probably do a similar thing with
graphics. FOTree is much more complex, and AreaTree has complexities for a
different reason.

> Can it be that we had the same idea at the same time again? 
> :-) Of course, having standardized validation messages and 
> such goes a bit beyond what I imagined, but that's ok.

Actually, I don't envision standardized validation messages, although that
would be OK. (I suppose you could even handle the multi-lingual aspects of
that in a nice way.) I think that the original thread was dealing with how
the exceptions should be thrown, and that *would* be a good thing to
standardize, but different applications might want to handle them
differently.

I would characterize the two ideas as different, but very compatible, and
thinking along the same general lines. What you have done with JAFOP could
easily be a part of aXSL (or vice versa), and I would be glad to have you
participate, when the appropriate time comes.

Victor Mote

Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

[Jeremias Maerki <de...@greenmail.ch>]

Victor,

from the website I don't quite get the scope of the project. That might
have to be made clearer. Anyway, I didn't want to talk about it just yet,
because it's not ready, but recently I started writing a JAXP-like API
for XSL-FO processors (I called in JAFOP for now). It basically
implements the ideas we came up with in the API discussion over a year
ago. In the next few months I will probably need to integrate several
different FO-processors and want to have a common API for all.
Especially having a uniform API between FOP maintenance branch and HEAD
is important to me because I need to get FOP 0.20.5 set up for PDF
output and I will most probably need the RTF output of FOP HEAD quite
soon (all in the same VM, of course). Also, the fact that we got 4
OS-FO-processors screams for a common API so they can be used
interchangeably.

Can it be that we had the same idea at the same time again? :-) Of
course, having standardized validation messages and such goes a bit
beyond what I imagined, but that's ok.

On 04.11.2004 22:58:39 Victor Mote wrote:
> Finn Bock wrote:
> 
> > Do you mean that the 3 different processors should ideally 
> > report the same validation errors in the same manner? That 
> > can only happen after someone standardize a SAFO API (Simple 
> > API for FO parsing). Until then all implementation will throw 
> > different exceptions, which is fine by me.
> 
> I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
> already taken, but at the time I registered the axsl.org domain, and I
> finally went ahead yesterday and opened up a SourceForge project for it.
> There isn't much content there now, and I doubt that anyone wants to spend
> much time on it ATM, but we have a place to talk about such things for those
> who are interested -- I think Joerg at least will appreciate it being
> somewhere else, and I know there are others who are not interested as well.
> It deals with more than just parsing and exceptions, but those are (or could
> be) parts of it. Here is the website:
> www.aXSL.org
> 
> If FOP is interested, you are welcome to send a delegate, who will
> automatically become a committer. Also, Peter West is welcome to be a
> committer -- if we can accommodate his design, we'll sure try. I'll
> eventually invite the commercial developers too, if it looks like there is
> anything here that helps.



Jeremias Maerki

aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

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

Finn Bock wrote:

> Do you mean that the 3 different processors should ideally 
> report the same validation errors in the same manner? That 
> can only happen after someone standardize a SAFO API (Simple 
> API for FO parsing). Until then all implementation will throw 
> different exceptions, which is fine by me.

I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
already taken, but at the time I registered the axsl.org domain, and I
finally went ahead yesterday and opened up a SourceForge project for it.
There isn't much content there now, and I doubt that anyone wants to spend
much time on it ATM, but we have a place to talk about such things for those
who are interested -- I think Joerg at least will appreciate it being
somewhere else, and I know there are others who are not interested as well.
It deals with more than just parsing and exceptions, but those are (or could
be) parts of it. Here is the website:
www.aXSL.org

If FOP is interested, you are welcome to send a delegate, who will
automatically become a committer. Also, Peter West is welcome to be a
committer -- if we can accommodate his design, we'll sure try. I'll
eventually invite the commercial developers too, if it looks like there is
anything here that helps.

Victor Mote