My inclination is still (1) by default, but a very simple "-r" or similar flag for command line usage for relaxed validation.
Next, for any validation error *in which FOP can also handle relaxed validation*, such as fo:table-body currently and perhaps fo:block-container in the future, for FOP to print out an additional message that you can use "-r" or sSV(false) to turn off validation of this FO. This way the newbie with the bad table on page 157 still gets informed on default, but can quickly use -r if he/she doesn't care. Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Almost sounds like we end up with 3 operating modes: > > 1. production (strict validation, early halt) > 2. production-relaxed (relaxed validation, no halt > but with error > messages) > 3. development (strict validation, exception/halt at > the end after the > output is generated) > > (following Glen, 1 would be the default) > > Just as an idea: this could also be set through a > custom attribute in > the FO file instead of (or in addition to) setting a > parameter from the > command-line or through the API. > > Anyway, I think Glen and Chris both raise valid > points. Now we need to > decide what we really want to do. Personally, I was > always happy with > the mode 2 above, so I don't have a strong opinion > towards any solution, > as long as mode 2 is available. Doing it like > described above is ok with > me. > > On 18.04.2005 10:24:30 Chris Bowditch wrote: > > Glen Mazza wrote: > > > Team, > > > > <snip/> > > > > > > > > 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. > > > > Both of these points are valid concerns. What the > software developed by my > > company does, is it gives the user a flag: Error > on Warning, which places the > > choice firmly with the user. The software then > scans the log and halts the job > > before it is sent to the printer if this flag is > set. However, there are many > > sceanrios where it is not desirable to just halt, > hence why this decision > > should be up to the user not the FOP development > team. An example of a > > situation where just always halting would be bad: > > > > Our software allows users to preview what their > document looks like before it > > goes into production. I would imagine most > stylesheet designers would preview > > their work before releasing it to a production > environment. If the user is > > just presented with an error message, with no > output then the user will have > > to trawl through various places to work out what > theyve done wrong. If they > > have the output and an error, it is easier for the > user to locate the problem. > > > > <snip/> > > > > Chris > > > > Jeremias Maerki > >
