On 23/08/2011 12:03, Ulrike Fischer wrote:
>> Well no, as the special 'unknown' key allows behaviour for a key which
>> is not defined to be set up.
> 
> Does keys_set_known makes a difference between modules with and
> without such an unknown key?  

The current approach is that \keys_set_known:nnN only sets
explicitly-defined keys. So it does not matter if a set of keys have an
'unknown' value or not. (I'm not quite clear why you'd want to do
\keys_set_known:nnN with an 'unknown' value set if this meant that there
was no difference to just using \keys_set:nn.)

> I'm currently changing chessfss to keyval-syntax. I have to set
> properties for board fonts, figurines fonts and other symbols. So I
> have a structure like this:
> 
> all chess fonts
>   family
>   width
>   series
>   size
>   
> fig font
>   encoding
>   family
>   width
>   series
>   size
> 
> board font
>   encoding
>   family
>   width
>   series
>   size
> 
> ...
> 
> So keys like "fig / encoding" look quite natural, but it would be
> quite useful if a user could set keys also like this:
> 
> set-all, family=...
> 
> set-fig, family=...  , size= ...

At a technical level, this can be supported. However, my concern is more
at the conceptual level. In most programming languages, keyval input is
used to replace positional parameters by named ones. On the other hand,
the pgfkeys approach inter-mixes named parameters with executed items.
At present, the approach in l3keys when setting keys is rather more
toward the 'named parameters' approach.

Now, it may be that practical considerations mean that something more
like the pgfkeys approach is actually the best plan. However, I guess I
need a bit more convincing. For example, in siunitx I have a similar
issue, and in the end went for something like

\keys_define:nn { module }
  {
    thing .meta:n = { subgroup-a-thing = #1 , subgroup-b-thing = #1 },
    subgroup-a-thing .code:n = ... ,
    subgroup-b-thing .code:n = ... ,
  }

but did wonder if

\keys_define:nn { module }
  {
    thing .meta:n =
      { subgroup-a / thing = #1 , subgroup-b / thing = #1 },
    subgroup-a / thing .code:n = ... ,
    subgroup-b / thing .code:n = ... ,
  }

might have been clearer.
-- 
Joseph Wright