User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
References: <48C2348C.908@morningstar2.co.uk>
            <859ec5630809080556g36259d1fnd01204c84a3a8adf@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <48C579E8.4020704@morningstar2.co.uk>
Date:         Mon, 8 Sep 2008 20:15:52 +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: keyval
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <859ec5630809080556g36259d1fnd01204c84a3a8adf@mail.gmail.com>
Precedence: list
Status: R

Morten Høgholm wrote:
> On Sat, Sep 6, 2008 at 9:43 AM, Joseph Wright
> <joseph.wright@morningstar2.co.uk> wrote:
> 
>> I've been looking at the current expl3 work, and I'm wondering about the
>> planned direction with keyval stuff.  The current l3keyval only covers
>> some very basic functions, and it's not clear to me whether this will be
>> extended to higher-level commands.
> 
> It will. So far only data extraction was done because a) it was needed
> and b) I need to sit down, preferably with someone, and take a good
> look at how to tackle this. Judging from the hacks we see in pstricks
> and many other packages, the current approach as implemented in keyval
> is insufficient. The model used in pgf looks interesting.

I agree.  I think overall the idea of separating "properties" of keys is
much bettr than (say) xkeyval.
> 
> How the keyvals are used depends on the circumstances. If you take a
> look at template, it both runs traditional "turn key into csname, then
> assign it a value" but also contains a more complex run when declaring
> the template. In the latter instance, the value in fact consists of
> individual values, each requiring different action.

That might be a challenge.  I was mainly thinking about providing a way
for programmers to set up options, etc.  I suspect template will push
everything.

>> [snip] if no-one else is likely to
>> work on this in the near future I can perhaps see whether I can produce
>> some basic macros in this area (for preference I'd probably adopt the
>> pgfopts model, which I find quite accessible).
> 
> Please do go ahead.
> 

Okay, I will have a look at this.  For first preference, I might use the
pgfopts syntax:

/<module>/<description>/.<property>

although I suppose:

<module>_<description>.<property>

or

<module>_<description>:<property>

might both be more in line with the LaTeX3 system. However, I think the
analogy with UNIX paths works quite nicely for the pgfopts approach.
-- 
Joseph Wright