Re: [xsl] Limitation of <xsl:result-document> in <xsl:function> in XSLT2

Subject: Re: [xsl] Limitation of <xsl:result-document> in <xsl:function> in XSLT2
From: "Kurt Cagle" <kurt@xxxxxxxxxxxxx>
Date: Wed, 9 Apr 2003 13:46:48 -0700
Isn't this splitting hairs? To me, there is no real distinction between

<xsl:template match="foo">
     <xsl:call-template name="outputBar">
            <xsl:with-param name="filename" select="'foobar.xml'"/>
            <xsl:with-param name="data" select="."/>
     </xsl:call-template>
</xsl:template>

<xsl:template name="outputBar">
            <xsl:param name="filename"/>
            <xsl:param name="data"/>
            <xsl:result-document href="{$filename}">
                <xsl:copy-of select="$data"/>
            </xsl:result-document>
</xsl:template>

and

<xsl:template match="foo">
     <xsl:value-of select="outputBar('foobar.xml',.)"/>
</xsl:template>

<xsl:function name="outputBar">
            <xsl:param name="filename"/>
            <xsl:param name="data"/>
            <xsl:result-document href="{$filename}">
                <xsl:copy-of select="$data"/>
            </xsl:result-document>
            <xsl:result></xsl:result>
</xsl:function>

Neither produces primary stream output, both induce side-effects. The
function can produce output (that's one of the compelling arguments for
having functions in the first place) as readily as the named template can.
The distinction between the named template and the function derives
principally from the fact that the function interprets its parameters
positionally, while the named template uses named keys.

To me <xsl:result-document> is a ready admission that the purely functional
model of XSLT will not strictly work, because it implicitly produces side
effects (you're potentially changing external state). Either acknowledge the
fact that there will be some effects that break the functional model for the
sake of usability (something which I personally would vote for) or remove
the <result-document> from contention in the model and then add it in as an
extension (thus breaking portability).

Sorry for being peevish. I'm working on a book on XSLT2, and am beginning to
heavily test the spec as a consequence. I understand the motivations behind
wanting to keep XSLT strictly functional, but most of those arguments go
down the drain the moment that you add extensibility to the mix; to me it
would be better to control the obvious points of contention (such as the IO
mechanism implicit in result-document) so that they do remain standard from
implementation to implementation, rather than eliminating them altogether
and forcing even more fragmentation in the standard.

-- Kurt

----- Original Message -----
From: "Michael Kay" <mhk@xxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, April 09, 2003 11:28 AM
Subject: RE: [xsl] Limitation of <xsl:result-document> in <xsl:function> in
XSLT2


> > <xsl:function> may only contain <xsl:param>, <xsl:variable>,
> > <xsl:message> and <xsl:result>.  If you need to execute
> > <xsl:result-document> from within a function, you will
> > probably have to hide it inside an <xsl:variable>.
>
> No, that's banned too. xsl:result-document can only be used while
> writing a final result tree. In effect, the secondary result tree is
> seen as an branch of the primary result tree, that happens to be
> serialized to a different file.
>
> Michael Kay
> Software AG
> home: Michael.H.Kay@xxxxxxxxxxxx
> work: Michael.Kay@xxxxxxxxxxxxxx
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>



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


Current Thread