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
