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
> 
> 

Reply via email to