References: <m3k34m4vjd.fsf@somewhere.org> <5429D0DF.7060608@morningstar2.co.uk>
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:  <m3k34lrqkb.fsf@example.com>
Date:         Tue, 30 Sep 2014 19:00:52 +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:  <5429D0DF.7060608@morningstar2.co.uk> (Joseph Wright's message of
              "Mon, 29 Sep 2014 22:36:31 +0100")
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

Le 29/09/14 à 23h36, Joseph Wright
<joseph.wright-NisN+YXOI8VaA8anhhA8LJ6WHSJbwjtC@public.gmane.org>
a écrit :

> Sean has pointed to a similarity to dealing with mandatory arguments at
> a design level. This request seems a little different as l3keys isn't
> meant to be targeting that area. However, there is clearly overlap.

OK.

> At present, key properties mainly apply to individual keys in a 'stand
> alone' sense. This request is different as it's actually about an entire
> set of keys.

No, maybe I was unclear: my question concerned the "requireness" of
a single (or maybe several but treated separately) key property.

> To me, that seems a bit odd: it's pretty rare that buried inside a set
> of optional settings is one or more mandatory ones. There is also the
> question of what 'required' might mean, as
>
>     key = \empty
>
> or similar might well be equally invalid in the real use case but would
> presumably pass such a test.

In the use case I have in mind, `key' would be required and expect an
integer. Would it be missing, an error message would be emitted; would
its value be anything but an integer, an(other) error message would be
emitted.

> What I think we need before we can really comment is some solid proposed
> use cases, showing why the property is needed as opposed to other
> approaches as you outline.

Here is an outline of my use case. I'm working on a class for
a quarterly mathematical journal and I'd like to provide an \issuesetup
document command that lets the secretary specify, for each issue, at
least the (mandatory) number. The issue's month and year are computed
from the number but I'd like to let them be (optionally) specified if,
for any reason, a given issue is not published at time.

OK, this \issuesetup command could (and I started like this) be designed
to have a mandatory argument for the number and an optional argument for
specifying the month and the year in a key-value fashion:

  ┌────
  │ \issuesetup{143}
  └────
or:
  ┌────
  │ \issuesetup[month=3]{143}
  └────
or:
  ┌────
  │ \issuesetup[month=3,year=2016]{143}
  └────

but it is less explicit than:

  ┌────
  │ \issuesetup{number=143}
  └────
or:
  ┌────
  │ \issuesetup{month=3,number=143}
  └────
or:
  ┌────
  │ \issuesetup{month=3,year=2016,number=143}
  └────

OK, I could give a more explicit name: \issuenumber rather than
\issuesetup but:

1. \issuenumber[month=3,year=2016]{143} would look rather strange (has
   a "number" an optional "month"?)
2. other properties than just the number (and related month and year)
   could be added in the issue setup, hence \issuesetup is a more
   appropriate name than \issuenumber.

Thanks.
-- 
Denis