References: <m3k34m4vjd.fsf@somewhere.org>
            <5429D0DF.7060608@morningstar2.co.uk> <m3k34lrqkb.fsf@example.com>
            <10k836fpz0maa.dlg@nililand.de> <m3lhozrgp6.fsf@example.com>
            <zqejj1e7vcjn$.dlg@nililand.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Message-ID:  <m34mvnre7x.fsf@example.com>
Date:         Wed, 1 Oct 2014 17:39:46 +0200
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: =?utf-8?Q?Denis_Bitouz=C3=A9?=
              <denis.bitouze@LMPA.UNIV-LITTORAL.FR>
Subject: Re: [l3keys] Suggestion: Add a key property for specifying key that /has/ to be used
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <zqejj1e7vcjn$.dlg@nililand.de> (Ulrike Fischer's message of
              "Wed, 1 Oct 2014 17:06:46 +0200")
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

Le 01/10/14 à 17h06, Ulrike Fischer
<news3-x73OiligfUT+tKtrA809HA@public.gmane.org> a écrit :

> Am Wed, 1 Oct 2014 16:46:13 +0200 schrieb
> denis.bitouze-/xtQRdnxTdLaUcvLomQ+0NOM1ZH/LfCJ@public.gmane.org:
>
>>> It is normally not the *key* that is required but a *value*
>> 
>> Except if some keys are considered as mandatory arguments (and they
>> could not be turned into arguments because keys are much more explicit
>> than arguments).
>
> No, it is still the value you want. E.g assume that beside your keys
> you also define a key numbermonth=143/6 and a key
> numberdate=143/6/2014 and a key extranumber=143/b and a key
> issuenumber as alias to number. All set the needed value 143. 
>
> So which key do you want to declare as required? 

Now I see what you mean and I agree with you. But I guess I'd choose the
second case between the two following cases:

1. deliberately providing a many-to-one relation between keys and value,
   and writing code that ensures all these values of all theses *number*
   keys lead to the single issue's number,
2. be careful in providing a one-to-one relation between a single
   "number" key and issue's number value, and being able to specify that
   this key is required.

>>> Imho it is easier and more logical to test for the value and emit an
>>> error if is doesn't exist.
>  
>> OK but, AFAICS, there isn't any high level key property for this (and
>> that's the point of this thread): 
>
> The question is if the high level key property is the correct place
> to declare such a requirement on a value. 

I must admit that's an open question :)

>>> (Actually I wouldn't emit an error. As almost everyone is using
>>> scrollmode today error message are often ignored.
>  
>> Most of the TeX editors highlight errors, no? At least it is the case
>> for TeXstudio, for instance.
>
> Sure but a lot of users tend to ignore them as long as the document
> compiles. They often don't understand what the error means and so
> turn a blind eye on it. You wouldn't believe how many people start
> the correct errors only when the 100-error limit is reached and
> nothing works ;-)

I must admit that's a closed question ;)
-- 
Denis