--- 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. Technical reasons: 1.) Your content model change is not in agreement with either the 1.0 or 1.1 spec. You did not make a request to the W3C recommending that they make the change to the specification. Our responsibility is to implement the standard, if we need to diverge from it we need to inform them first. I already explained to you[1], via fo:wrapper and fo:page-sequence-wrapper, that they already make allowances in order to ease coding. (Even though I may not like those changes personally.) We are not like a commercial product where we can just ignore the content models, we have a charter and a community responsibility to fulfill. 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. 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? 4.) The change involved would leave vague of how to implement a table header if there is no table-body, worse, it would lead to abuse of the fo:table to just have headers printed. None of this is backed up by the spec--we would be in fantasyland on how to interpret fo:tables without fo:table-bodies. 5.) You're relying a dubious distinction of strict vs. relaxed validation, which has no basis in the spec. The content models for the FO's form the contract of the language that the XSL processor is to accept. Not validating at the source requires more & repeated checking downstream, clogging the logic in those places, and creating far more sources of error. All this for an item that you yourself say is of no practical use? 6.) Adhering to the XSL model makes the Apache FOP process the gold standard of validators--an XSL file is not legitimate unless FOP accepts it. Painting FOP as a reference implementation will do wonders for us, just as it has for Tomcat. I *will* support divergences from it, but we have to (1) discuss it beforehand, (2) there has to be a legitimate reason for it--not just saving someone a five-line XSLT template that should be properly written anyway--(3) and explain to the W3C our suggestion first. 7.) I already implemented the official validation. You cannot remove it and then tell me if I want it I have to reimplement it again in a different manner. The burden is on you for that. Our validation unit has to be able to support the spec. 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. 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. Glen [1] http://marc.theaimsgroup.com/?l=fop-dev&m=110922603225376&w=2 [2] http://marc.theaimsgroup.com/?l=fop-dev&m=110930040205336&w=2
