--- Glen Mazza <[EMAIL PROTECTED]> wrote: > > Jeremias, > > This should not be done. If someone has a problem > with it--and I've never heard a complaint--they can > send an email to xsl-editors, for them to adjust the > content model for fo:table accordingly. (If they > don't, they don't.) >
To elaborate, I also frequently have problems with certain content models, but what I do is send requests to the xsl-editors list[1] when I have them (for example, [2, #61], and several others). I think it would be best for you to do that before considering making the change with FOP. It may also encourage others to endorse your suggestion on the ML. But making the change without informing the W3C of what you see as an error doesn't help improve the standard. Also, IMO we should be encouraging unhappy users to register their complaints with the W3C so that they will indeed make these changes. (10, 15 complaints, they will!) In this way, FOP plays the role of a true reference implementation, with a nice circular, ongoing feedback with the W3C, and all FOP-accepted stylesheets will be guaranteed to work with other processors. We validate also to show newbie users what they are doing wrong. It gives nice correction and feedback to the user, just like compilation errors in Java give feedback to newbie developers. Validation serves a good purpose. [1] http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/ [2] http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0011.html > Note that the editors are very reasonable about > this--for example, fo:page-sequence-wrapper and > fo:wrapper are allowed to have no children for > programmatic convenience, even though it doesn't > make > sense for these items to be empty. > And in #61, you can see I don't like empty fo:page-sequence-wrappers or fo:wrappers either. ;) > BTW, what is FONode.removeChild() for anyway? Why > is > this helpful--we haven't needed such a method for > years. > Sorry, I was wrong here--we have indeed needed such a method, until about December ([3], emails 9, 7, 6). We used to have addLayoutManager() in the FO's in which the FO would determine whether or not it was empty, and if not, attach itself to a Layout Manager. (Email #9) I kind of preferred this implementation, as it allowed us to keep the internal state of each FO internal, rather than need to expose its internal variables to another object that would subsequently read inside it to make the empty-or-not determination for the FO. Simon moved us away from that (Email #7 of [3]) because he didn't want the FO's to have knowledge of layout managers, and wanted to move us from (1) having the FO decide whether or not to attach itself to a LM to (2) having a layout manager decide whether or not to process an empty FO. This is not my preferred implementation, but it seems an acceptable interpretation. But your removeNode() function seems to be bouncing back to the original implementation now: let the FO decide. Can we make a decision and settle on one or the other here? Do we really have to do both? Also, my main problem with Simon's implementation, was that (as mentioned above) the FO's needed to expose their internal state more to the LayoutManagerMaker object so the latter could determine if it needed to process that FO. I think Simon saw that a little as well, and what I recommended in Email #6 was that we have an boolean FONode.isEmpty() that the LayoutManagerMakers can read, and if it returns true, to not process the FO. Question: can we use a boolean isEmpty() instead of your removeNode()? We can then much better encapsulate each FO (i.e., instead of having a LMM read variable a, b, and c of an FO to see if it needs processing, it can just check isEmpty()). Sorry for the long post. Thanks, Glen [3] http://marc.theaimsgroup.com/?t=110286102900001&r=1&w=2
