Morten Høgholm wrote:
> On Sat, Sep 6, 2008 at 9:43 AM, Joseph Wright
> <[log in to unmask]> 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