Re: XPath equivalent to xsl:apply-templates?

On Mon, Jun 13, 2022 at 01:55:39PM -0000, Michael Kay mike@xxxxxxxxxxxx scripsit:
> I agree a functional equivalent to apply-templates would be useful.
> 
> In trying to design it, the main stumbling block has been how to handle modes. We could make the mode-name a dynamically-defined QName argument, but that's then a new capability (dynamic modes) rather than a functional equivalent, and it raises questions in the context of 3.0 mode visibility and packages.
> 
> An alternative design would be to use the mode name as the function name, or to find some other way of statically associating a function with a specific mode.

This strikes me as adding an imaginary component to the function arity.

So where now there's

local:doesThing#2
local:doesThing#4

there'd be

local:doesThing#2@current
local:doesThing#4@current
local:doesThing#3@userDefined

(The choice of @ to indicate the mode is completely questionable, but there isn't a lot of punctuation just lying around unused.)

By default, every function is in the special mode current; a user can specify they want a specific mode through some sort of semi-parameter mechanism so local:doesThing($a,$b) does what you'd expect but local:doesThing($a,$b,$c)@userDefined (or maybe local:doesThing@userDefined($a,$b,$c) goes and finds the definition from

<xsl:function name="local:doesThing" mode="userDefined as="returnType">
....
</xsl:function>

or

declare function local:doesThing($a,$b,$c) as returnType mode userDefined {
....
};

In the specific case, it'd look like

fn:apply-templates@modeName($someNodes)

or (for #CURRENT or #DEFAULT and I'm not clear on which it should be)

fn:apply-templates($someNodes)


I am not sure the complexity is worth the convenience but it would certainly be nice to have sometimes.


-- 
Graydon Saunders  | graydonish@xxxxxxxxx
^fs oferiode, pisses swa mfg.
-- Deor  ("That passed, so may this.")