Team, I have been thinking more about our decision to not validate by default the fo:table-body within the fo:table (i.e., our FOUserAgent.setStrictValidation() is initialized to "false".) I have found newer concerns since then that I want to make sure the team is at least aware of.
As a review: The XSL content model for fo:table-body is this: (table-row+|table-cell+) (+ = 1 or more) FOP (both versions, as well as every commercial version Jeremias could find) is using this instead: (table-row*|table-cell*) (* = 0 or more) (i.e., not halting, but giving an error message in the logfile if no rows/cells found.) My newer concerns are: fo:table-rows are commonly generated by a xsl:template separate from the xsl:template that generates the fo:table (because the rows have common formatting characteristics, etc.) If the user makes a mistake with the xsl:template "match" attribute that activates the fo:table-row template, or if there is an error in (say) the SQL which generated the input XML, no rows will be matched, and the user will incorrectly have an empty table. These are pretty common errors in XSLT that would cause the output document to need to be regenerated anyway. Take two scenarios here: 1.) 200-page report containing dozens of tables. If the user messes up the template match for any of those tables, that 200-page report just printed will need to be redone. But if we validate (i.e. halt) by default we may very well have saved someone 200 sheets of paper. Relying on the user to scan FOP's output log after a document run to determine whether or not their document had every table generated properly would be IMO too irritating for the majority of users. They are more likely to print a document without noticing that the table on page 157 is erroneously empty. For these users, I think they would have been happier had FOP halted and informed them of their bug instead. 2.) Invoice statements going out to large numbers of customers. It can happen for SQL errors to occur that erroneously result in no XML rows being available for certain of the invoices. Under these conditions, wouldn't most people in charge of the invoices be happier if FOP halted with the error message, rather than send erroneous invoices to those customers? (It wouldn't matter if an error message was written to the logfile--that invoice would still be going out.) Not validating can introduce some nasty risks with invoices--it is usually safer not to print it at all then to send a bad invoice. Not validating by default is certainly survivable for us--indeed, none of the implementations in use currently do, as Jeremias has noted. But many/most people are not going to be aware of the setStrictValidation() method until *after* a bad production error occurred. The team may wish to consider if it would be better for everyone if we told users who were annoyed about using xsl:if[1] to suppress invalid empty tables to just set sSV(false), rather than be in the unfortunate position of telling others who have just sent out hundreds of bad invoices/documents to set sSV(true) next time. Thanks, Glen [1] http://marc.theaimsgroup.com/?l=fop-user&m=110969361317977&w=2
