Re: Designs for XSLT functions (Was: Re: RE: syntax su

Jeni Tennison wrote:

...
> 
> I take your argument, and especially for a different syntax to a
> function based if(). I think it's likely that XPath 2.0 will support
> such things - it's on their list of requirements. However, I'd like to
> focus the discussion on things that we (the community) can achieve
> rather than things that only the WG can achieve.
... 
> Sure, and I'm *incredibly* glad to see that. As I said above, though,
> I'd like to focus on what is achievable now rather than with XSLT 2.0.
> I also think that just because this particular example will be
> addressed in XSLT 2.0 doesn't mean that there aren't examples that
> won't be.

I have wailed about parts of the XSLT 1.1 proposal, but I feel that we -
the XSLT community - will achieve more if we build on each other's
efforts. Given the choice between an approach which slots into XSLT 1.1
and the 1.1 / 2.0 schedule and one which ignores both, I think the first
approach has a higher chance of widespread adoption and widespread user
benefit.

> For reasons noted previously in this thread, it's not sufficient to
> return a copy of the node you want - it has to be the node itself.  In
> this example, under your proposal I would have to do:
> 
> <exsl:function name="my:first-alphabetical">
>    <xsl:param name="nodes" />
>    <xsl:variable name="first-node">
>       <xsl:for-each select="$nodes">
>          <xsl:sort />
>          <xsl:if test="position() = 1">
>             <xsl:value-of select="generate-id()" />
>          </xsl:if>
>       </xsl:for-each>
>    </xsl:variable>
>    <exsl:result select="$nodes[generate-id() = $first-node]" />
> </exsl:function>
> 
> It's certainly not impossible, just slightly more laborious.

Ouch! Please not unless there is some overwhelming reason for this.

> Hmm... perhaps rather than imagining it as a preemptive return we can
> imagine it building up exsl:return elements within a result node set.
> So essentially the result of calling an exsl:function is a number of
> exsl:return instructions.  The first one of those is chosen and the
> select expression (or the content) is evaluated to give the value of
> the function.  Of course implementers would be free to optimise by
> stopping the function when the first exsl:return is generated.
> 
Makes sense - and is compatible with the general XSLT treatment of
node-list arguments to functions which basically expect a single
argument, eg (from memory) generate-id().

Many thanks to all who are helping move this on -

Francis.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list