User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0)
            Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <CAM2dePV5k2+Q+H=jCj=bsvc-hWanc3_CLYw1-ukhB8UMhzU_Lw@mail.gmail.com> <51C94FA0.1080803@morningstar2.co.uk> 
            <CAM2dePUfzF_Bj5QX7qbAmsyO7Udjy1yb5j43zTVexOwG2rmtVQ@mail.gmail.com> <51DD0EBD.6080308@morningstar2.co.uk> 
            <CAM2dePUxFs1eNU1iTCrnp=CbDFo1eMjE813gZQH3vVhBkH=zDg@mail.gmail.com> <51DF2000.30703@morningstar2.co.uk>   
            <CAM2dePW67rUcSRqRYEeccS6AUVmGjW5XuY74ZCYPfgqObK=BcA@mail.gmail.com>           
            <51E12031.4060600@morningstar2.co.uk>
            <CAM2dePUp90ehRiipJF+mHVZUYksVbrbP7gKS=zJvdJyCD8JSjQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <51E2FFC0.6010209@morningstar2.co.uk>
Date:         Sun, 14 Jul 2013 20:45:04 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: l3keys feature request
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CAM2dePUp90ehRiipJF+mHVZUYksVbrbP7gKS=zJvdJyCD8JSjQ@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 13/07/2013 17:01, Jura Pintar wrote:
> I'm still not entirely sure about the handling of unknown keys. On the
> one hand, I think there is a substantial conceptual difference between
> keys that shouldn't be set because they're not in a group on the
> 'opt-in' list or they're in a group on the 'opt-out' list, and keys
> that cannot be set because they're undefined. For one, I expect users
> are likely to pass a disallowed key to a document command because
> they've not read the the documentation carefully enough (and then such
> a key can be filtered out), but when they pass an undefined key,
> they're likelier to have just made a typo. So they should get
> different notifications in the two cases. On the other hand, I agree
> that passing an undefined key to \keys_set_groups:nnn should normally
> be less bad than passing such a key to \keys_set_filtered:nnn. Maybe
> unknown key errors should be demoted to warnings in this case?

For the moment I've gone with my simpler separation of 'keys which have
been set' and 'keys which have not'. I've yet to write the docs, which
may reveal issues, but my thinking currently is that key filtering is a
way to assign only some keys in particular contexts, but that elsewhere
either the 'balance' will be set or all keys will be set

  \key_set_groups:n { module } { group-a } { ... }

  ...


  \key_set_filter:n { module } { group-a } { ... }

so unknown keys should turn up. I'm not seeing the need to using groups
to separate out keys such that the 'balance' are never set: we have
\keys_set_known:nn and different paths for such cases.
-- 
Joseph Wright