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

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.  



Reply via email to