Hello Will,

> I've even toyed with the idea, when dealing with keyval input in
> fontspec, (never happened though) of normalising all keyval input by
> stripping spaces and hyphens, and lowercasing the result. So the
> following would all be equivalent:
>   number case=
>   NumberCase=
>   Number-case=
> and so on.
> 
> Not actually sure if that would be a good idea (one person commented
> something like "why reward the user for incorrect input?"). Easier for
> the user, however, who must deal with multiple packages in which one has
> CamelCaseKeys, another "keys with spaces", another with keysruntogether.

I'd imagine that, like many things, LaTeX3 should establish a convention
on this type of thing. At the moment, template uses hyphenation, so I
guess this may be the convention. I use "everything runs together" in
siunitx at the moment, but I think this was a bad choice, as it makes it
hard to create readable names.  I tend to think that spaces are fine, as
I find the pgfkeys keys very readable. (Not sure normalising things is a
great idea: as you say, one is correct and the rest are wrong!)

> Regarding keys3 vs template, I'm still firmly on the fence. I think I
> need to implement something reasonably complex from scratch and see how
> both fare. One thing that template seems to do nicely is inheritance;
> what would be the equivalent process in keys3?

keys3 is meant to be an experiment to see what needs to be thought
about. I'd still imagine that the final result might well be something
else (although I'm quite happy to write it). I'm simply aware that at
present we don't have a native LaTeX3 solution which covers everything
that can be done in xkveyval/kvoptions/pgfkeys plus template, and I'd
suggest we should.

On inheritance, I know that the pgf team have looked at things, but I'm
not happy that they've got an understandable system.  Could you give an
example of how tempate does this: I must have missed it in the docs.
Then I can think about it!

> To the advantage of keys3, I agree that being able to change the default
> value of a key independently is very desirable. 

Yes, I'd say so. The default might change depending on other choices,
for example.

> Another feature that
> template doesn't support as easily is the idea of an explicit set of
> named options such as keys3's .create_choices:nn and xkeyval's
> \[log in to unmask]

Options are in pgfkeys, but in addition I tried to emulate xkeyval's
\define@choicekey in keys3. The idea was that you can make lots of
similar choices easily.  If we go with a template-like system with will
be one to consider. I do like the idea that pgfkeys allows easy creation
of complex choices, where each choice "does its own thing". That is not
so easy in xkeyval.

> I'd like to explore the idea of auto-detecting the variable type (by
> stripping off and examining the trailing "_xyz" of the variable) to
> determine which _set function should be used; this could simplify many
> of the common use cases for both packages. Since it would only need to
> be done when first setting up the key, the performance hit should be
> completely reasonable.
> 
> After all, what's the point of having some nicely rigid naming schemes
> if we never take advantage of them? :) But even better is that this
> scheme could allow assignments to other types of variables (such as
> clists) without any extra work.
> 
> E.g.,
> 
> \keys_manage:nn {module/caption/} {
>    above-skip/.set:N = \l_caption_above_skip ,
>    above-skip/.default:n = 5mm ,
>    caption-name/.set:N = \l_caption_name_tl ,
>    caption-name/.default:n = {Figure}
> }
> 
> or
> 
> \DeclareTemplate{module}{caption}{4}{
>   above-skip = n [5mm] \l_caption_above_skip ,
>   caption-name = n [Figure] \l_caption_name_tl
> }{...}

Not a bad idea.  One thing that comes to mind is the issue of creating
by name. I've done this in keys3 as you see this idea in the xkyeval
\define@cmdkeys macro, where you set up the prefix once then can make
lots of related storage macros.  On the other hand, is this useful
(template does not do it, I think)?  Perhaps it is better to do each one
explicitly, so that the code is clearer?

> Anyway, what I've said above doesn't really help the discussion much but
> it might spark a couple of new ideas.

I think it does.  What I'm hoping to get is an idea of what needs to be
available, and what interfaces work well.  This sort of thing is useful
in that regard. I'll see if keys3 can cover this type of thing, and if
not I've obviously got something wrong!

I should say that I'm *not* saying that keys3 is the correct approach,
simply that it is *an* approach.
-- 
Joseph Wright