Am Mon, 30 Mar 2015 13:46:52 +0100 schrieb David Carlisle:

> On 30/03/2015 13:11, Ulrike Fischer wrote:
>> The expanding use of key-val syntax in class and package options
>> means that packages can break due to unknown values. I just tumble
>> over this example in a real document:
>>
>> \documentclass[index=totoc]{scrbook} \usepackage{acro}
>> \begin{document} \end{document}
>>
>>
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! LaTeX error:
>> "kernel/boolean-values-only" ! ! Key 'index' accepts boolean values
>> only.
>>
>>
>> It is easy to provoke a similar error with e.g. siunitx:
>>
>> w \usepackage{siunitx} \begin{document} blub \end{document}
>>
>>
>> I'm wondering what could/should be done to avoid such situations.
>> Should package authors avoid package options altogether and use setup
>> commands? Or can they (how?) parse the keys in the option list in a
>> way which doesn't gives errors but imply ignores unknown values?
>> Should the documentclass filter the options? How?
>>
>>
>>
> 
> Ulrike, good question:-)
> 
> I know you know most of the answer below already but stating the obvious
> seemed a good place to start:-)
> 
> The standard option processing processes options from both the
> \usepackage and \documentclass commands, but in different modes
> so that unknown keys only generate an error if used directly
> on the package.
> 
> for KV options the problems seem to be
> 
> 1) There's no support in the kernel (possibly we could do something
> about that, but looked at it before but it's tricky, this code's a bit
> delicate and used in every latex document. There is a big incentive not
> to change it:-)
> 
> 2) there are two levels corresponding to "unknown option"
> the key not being known at all, or the value not being known
> for this key when handled by the package.
> 
> 
> (1) means there are several different package kv handlers around
> (directly in the file, as in hyperref, or versions for xkeyval, or
> kvoptions or l3keys ....
> 
> 
> It seems that currently typically unkown keys are being ignored but
> unknown values of "known" keys are generating an error.
> 
> Probably most compatible thing to do would be to process the
> documentclass options in a mode that both unknown keys and values
> were silently ignored, although there's an argument to say that
> once you start getting richer syntax like this, packages should stop
> handling the documentclass options, as weird effects will happen
> if the keys just happen to have the same name or compatible values.

Good summary ;-)

Imho packages in general would like to ignore 99% of all global
options anyway. So I'm inclined to say that this is the way package
authors should use. With l3keys2e you can do it with
\ProcessKeysPackageOptions, kvoptions are
\ProcessLocalKeyvalOptions.

But there remains a small number of options where propagation is
wanted: draft, final, language names comes to my mind. draft and
final are probably easy to catch, but language names are an open
list. 

On the side the syntax is starting to diverge here too. Looking at
babel options like "latin.medieval,main=english" or polyglossia
setting \setmainlanguage[spelling = new]{german} package authors
wouldn't have much joy with class options anyway and should better
use a combination of \languagename and own package options to set
languages. 


-- 
Ulrike Fischer 
http://www.troubleshooting-tex.de/