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
