Am Tue, 23 Aug 2011 17:39:18 +0100 schrieb Joseph Wright:

>>> 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 didn't want to do something, I only tried to understand the "side
effects" of using the "unknown" key.

> 
>> 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.

chessboard is doing it too. Once I got the knack on defining keys it
came quite naturally to use them not only to set width or size but
also to put and remove pieces, declare a color in one key, and with
the next key draw a rule in this color.

I realized only at the end that this was an quite unusual use of
keyval syntax. 

A "change path" command would be really useful here. Currently every
key must have an unique name, and this can give quite long names. 


> At present, the approach in l3keys when setting keys is rather more
> toward the 'named parameters' approach.

This is also the case with xkeyval and it could be used for the
other approach too ;-) I think l3keys is very powerful and quite fun
to use. 

-- 
Ulrike Fischer