Re: AW: Copy atrribute

Hello again,

Until I found a better way I was doing this:

<p:directory-list />

<p:label-elements match="c:file" attribute="path"
label="ancestor-or-self::*/@name => string-join('/')"/>

Interesting to note that using this step you can evaluate a path that looks
up the tree from the matched element - otherwise rather tricky to
accomplish in XProc without an XSLT (correct me if I'm wrong).

I don't mind that the step is called something odd or unexpected. In my
view, "tag abuse" is more than a poor fit between the name and the thing
named. It becomes a problem when the intended semantics are diluted, masked
or corrupted by the misuse. So tagging things as 'ship' to make them appear
in italics makes your ship index useless, etc. So, introducing ambiguity
across the data set.

By that rule, this is not tag abuse so much as creative or (ahem) 'off
label'. The problem isn't even in the name "label-elements" (even if not
perfect) but arguably in the name "add-attribute", for a step which in
its current form is more limited than one might expect.

If p:add-attribute had a 'calculated-value' in addition to (perhaps
overriding) 'attribute-value', for an XPath to be evaluated in the context
of the element being matched, we'd be done (wouldn't we?), and there would
be three ways to do it (counting p:xslt), not only two. Those who want can
use p:label-elements when they are actually making labels (whatever those
are).

My take, anyway! Thanks for reading,
Wendell









On Mon, Mar 24, 2025 at 10:23 AM Norm Tovey-Walsh <ndw@nwalsh.com> wrote:

> <denis.maier@unibe.ch> writes:
> > Is there something you can do with p:add-attribute, but not with
> p:label-elements? Otherwise, wouldn’t it make sense to just merge the steps
> into one?
>
> I’m not sure that’s an ideal criterion to use. After all, you could
> replace a whole lot of steps just with p:xslt by that metric.
>
> I think the semantics of p:label-elements are a fair bit more complex than
> the ones for p:add-attribute. Despite many years of having both, you’re the
> first person I know of who had a use case for adding attributes that wasn’t
> satisfied by p:add-attribute.
>
> And, semantics-wise, it’s interesting that your use case didn’t involve
> one of the key features of p:label-elements: the magic, and magically
> advancing, $p:index variable.
>
> When I’ve got more time, I’ll try to think through what a more generic
> version of add-attribute/label-elements/update-this-thing might look like.
> My intuition is that if you want it for adding attributes, you might
> equally want it for adding content; a sort of dynamic p:insert or
> something. But maybe that’s the point where you just step up and write some
> XSLT. I dunno.
>
> The step library, like the standard function library in a programming
> language, is a mixture of requirements and conveniences, an attempt to make
> it easy for users to find the thing they want, without providing so many
> things that it’s bewildering. Or any more bewildering,
> maybe. :-)
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norm Tovey-Walsh <ndw@nwalsh.com>
> https://norm.tovey-walsh.com/
>
> > Life always comes to a bad end.--Marcel Aymé
>


-- 
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...