User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
            Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <11lm3sqjz6xux$.dlg@nililand.de>                      
            <5595661F.1070304@morningstar2.co.uk>           
            <CA+jHFwSTVzJ4VYb9tF5n2tgX1hU821hG32_JKQLBfWVZ=SnxTQ@mail.gmail.com>           
            <55962878.5030204@morningstar2.co.uk> <bbkmg4gzwky6.dlg@nililand.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID:  <5596FA13.3000702@morningstar2.co.uk>
Date:         Fri, 3 Jul 2015 22:09:39 +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: Order of key declarations
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <bbkmg4gzwky6.dlg@nililand.de>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 03/07/2015 08:58, Ulrike Fischer wrote:
>>  - Order does not matter: just accumulate whatever is applied.
> 
> Order will naturally still matter if one declare mutually exclusive
> properties. So some clarification about which property overwrites
> another would be fine anyway.

Yes, I meant beyond that which is reasonably obvious from the normal
keyval behaviour that a list is read/applied sequentially. I will not
that point in the manual.

>>  - key .reset: zaps *everything* (could also be called key .delete:
>>    or key .clear).
> 
> Looking at the various properties I see the following distinct
> properties that one would perhaps want to reset 
> 
> .value_forbidden:
> .value_required:
> .groups:n
> .default:xx
> "known status"
> "action" (all the rest without .initial:, which you can't undo)
> 
> .default:xx, groups:n and "action" don't need imho some special
> care:
> 
> - .default:X can imho be reset with .default:n= {}.
> - .groups:n can imho be reset with  .groups:n = {}.

Not quite for the groups case, at least at present, as your code would
actually store an empty group rather than removing the data from the
internal prop that manages these things. That can however be adjusted.

> -  the action can be reset by setting a new action.

Indeed.

> Missing is ".value_not_required:" and ".value_not_forbidden:".

These cases where I think the reason we went with the silent reset in
the first place. I wanted as far as possible to keep things simple:
these names look a little awkward. I'm also not sure how such status
could be flipped without some change to the 'action'.

> Missing is an explicit ".unknown:", which would e.g. allow to remove
> choices from a key. An accompayning ".known:" which reactivates the
> key would be interesting too. (I don't know if the code allows
> this). 

As with most keyval implementations, keys exist if they have some code
defined in the right place. Activating/deactivating would therefore need
the code moving to some other location: seems rather awkward for little
gain.

> An additional ".delete:" which clears a key completly would be good
> too. 

I'll wait to see what others think and then look at this.
--
Joseph Wright