On 07/05/2012 02:41 PM, mehdi houshmand wrote:
Hi Chris/Glenn/Anyone else,

You say command-line options should override the fop.xconf values, which makes sense. But should not-given command-line options override fop.xconf values too? Bare with me here, there is sense in the folly of that sentence. Ok, so let's take the example above, with strict FO validation, from the command line you have two options:

1) fop -r ... <other args>

or

2) fop ... <other args>

Obviously in option 1, you'd want strict FO validation to be invoked, regardless of what's in the fop conf. But how do we treat option 2? We're not explicitly telling it NOT to validate strictly, so how would a user expect FOP to behave?

Unless an explicitly negating command-line option is specified, it should use the configuration. If you want a way to override a setting that's turned on in configuration, there needs to be a command-line syntax for negating options. Common ways programs do that are:

'n' prefix, eg:

  -nr

'+' for negation (ick!):

   fop +r

pre-fix negation argument that negates the next argument:

   fop -n -r
   fop '!' -r

case:

   fop -R

--
Craig Ringer