On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza wrote:
> 
> Jeremias, I'm going to veto (-1) your change.  I would
> like the content model restored to the XSL standard
> and the FONode.removeNode() method removed.

I support Jeremias' change, and vote +1.
 
> Technical reasons:
> 
> 2.)  You failed to explain how an empty fo:table-body
> could possibly be of use to stylesheet writers, or how
> it would simplify their work.  I was able to debunk
> what you wrote in my response[2].  All you did say was
> that it is illegal and not useful, basically
> strengthening my argument.

An application should serve its users. It may try to educate them
regarding valid input, but it should not be obnoxious about it. If the
interpretation of the input is unequivocal, the application may warn
the user, but should continue. 

I am not sure that an empty table-body falls in this category. If the
other elements of a table are there, an empty table-body feels like a
genuine error, which may not silently be passed over. Especially for
unattended environments a warning is rather weak, and easily goes
unnoticed. Could this present users with documents in which tables are
missing without the author being aware of it?

On the other hand, if ignoring an empty table-body has been the actual
situation for a long time, this is not the time for Jeremias to change
that. Therefore, I am in favour of leaving Jeremias' change as it is,
and wait for someone else to implement a more proper solution.
 
> 3.)  As I explained to you, due to the new
> relationship between FO's and LM's, our architecture
> no longer supports FO's deciding whether or not to be
> attached to a LM.  I gave you the opportunity to
> discuss moving back to the older architecture, but you
> chose to ignore it--instead challenging me to find a
> better way.  That was my question: do we need to move
> back to the old method?

It is the task of the FO module to create a data structure that
represents the fo input, so that the LM module can use it as its input
for the layout. That data structure is the FO tree with the property
values. The FO module should do everything that is needed for this
task: validating input, sending corresponding warning or error
messages to the user, deciding that a piece of input does not require
representation in the data structure and possibly removing
corresponding data that has already been created. Therefore I believe
that FONode.removeChild() is a proper task for the FO module.

You have a tendency to react to other people's coding by saying that
this is not the ideal final solution. If a person is solving one
problem, he cannot solve all related problems at the same time. Such
problems can be tackled at another time, and perhaps by another team
member. So, please, do not say that a solution is not everything, but
take the opportunity and tackle the problem that remains. Or, if you
have no time, watch it sit there and suffer. :)
 
Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Reply via email to