Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
Jeremias Maerki wrote: On 25.02.2005 07:21:25 Glen Mazza wrote: snip/ For the moment I'm not going to answer the veto itself. Your veto makes this situation a one against one. I have presented my reasons for the change and therefore, I request feedback from the rest of the committers on this matter even if it's just a short message. Jeremias: your change gets +1 from me. Glen: All Jeremias was doing was changing the code to prevent a rather nasty NPE in the event of an empty fo:table-body. Surely you cannot be arguging that the NPE be restored?!? Chris snip/
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
On Feb 24, 2005, at 10:21 PM, Glen Mazza wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: I have nothing more to say about this. I want to spend my time on more productive things now. 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. The change gets a +1 from me. I'm all for helping our community grow, and I believe that it takes a supportive environment for that to happen. Anything we can do to foster improvement can help, be it providing help on this list, or not scaring the bejeebers out of someone when we throw an NPE their way (a NPE? an NPE? who cares! :-)). Many of my early errors threw warnings instead of NPEs (overflowing table-cell content, unsupported [yet] attributes, etc.) helped me greatly. Some of them I chose to fix, and others I chose to ignore at the time, as the output worked. I can understand the reasoning for a veto... As an avid reader of A List Apart, and some of the other gung-ho standards proselytizers, I respect the desire to have well-written code. At the same time, I also am guilty of throwing the occasional box-model hack or Mozilla-specific CSS extension into my CSS (e.g., -moz-border-radius-topright: 20px;). However, I tend to err on the side of the supportive, hence my reasoning for supporting this change. I've long been annoyed that some browsers require a non-breaking space instead of a normal 'space' (tdnbsp;/td vs. td /td) in order to function correctly. Cheers! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
Jeremias, My veto still stands, along with the seven technical reasons given for it. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: On 25.02.2005 07:21:25 Glen Mazza wrote: snip/ For the moment I'm not going to answer the veto itself. Your veto makes this situation a one against one. I have presented my reasons for the change and therefore, I request feedback from the rest of the committers on this matter even if it's just a short message. Jeremias, I gave you a full, thorough, and respectfully written explanation of the issues involved. Not only did you mostly ignore it, but in your response you chose to use my earlier smaller email in order to give others the impression that I had nothing more to say. This is terrible leadership on your part--railroading a change without discussion and refusal to discuss the change afterwords. I simply can't support this behavior, hence my veto. It may well be that I'm overreacting here. If that is so, then I'd like an honest feedback from additional members in the team. You must see that with your history I learned to treat your vetoes with caution because of the many times you changed a -1 to a +1 later after a long discussion and a lot of power spent. There's tension between us two and that's bad. ATM I don't know how to resolve it. I tried to be as open as possible and to address any concerns you have. You have repeatedly brought very good points and for that I'm glad but you had to withdraw several vetoes after starting to realize that you were wrong and I've also seen behaviour from your part that I don't like. For example, starting sentences with Mein Freund, bla bla and then later accusing someone else in a different thread of being disrespectful. I didn't say anything about it then. (Also, apologies to Renaud for not speaking up. I didn't want to pour any oil into the fire at that time.) I tried to overlook that, but I have my limits. I sometimes wonder if you're not more of a blocker in this project than a pusher. I don't think I'm the only one thinking like this. You know what happend during the creation of the XML Graphics PMC. BTW, letting yourself be known to the W3C by writing to them on occasion would appear to be a smart move for you--I don't know why you are fighting this. I'm not fighting this. I've had no compelling reason and spare time to do this, yet. The current issue is no reason for me to write anything to the WG. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
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
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
Simon, Thanks for reading and responding to my concerns. I appreciate it. Your endorsement of this change is sufficient for me--I am withdrawing my veto. Regards, Glen --- Simon Pepping [EMAIL PROTECTED] wrote: 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.
