Subject: RE: [xsl] Limitation of <xsl:result-document> in <xsl:function> in XSLT2 From: "Michael Kay" <mhk@xxxxxxxxx> Date: Thu, 10 Apr 2003 00:09:50 +0100 |
> 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 difference is that the first one is allowed, the second one isn't, and the fact that the second one isn't allowed enables optimizations that are not possible for the first. Consider this: <xsl:template match="x"> <xsl:variable name="t" select="outputBar(...)"/> </xsl:template> Would you want to say that the variable must be evaluated, even though it is never referenced, because the expression it is bound to might have side-effects? Or would you want to say that it is implementation-defined whether the secondary output file gets written or not? The working group chose to keep things interoperable by banning this kind of side-effect. Yes, it's splitting hairs. That's what you have to do when you specify programming languages. Perhaps one day we'll find a way of managing the side-effects in a controlled way along the lines that Haskell uses. In the meantime, we prefer to be strict. xsl:result-document is designed as a way of producing multiple result documents, not as a way of breaking the no-side-effects rule of XSLT. 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Limitation of <xsl:result, Kurt Cagle | Thread | RE: [xsl] Limitation of <xsl:result, Michael Kay |
RE: [xsl] Saxon is adding line brea, Michael Kay | Date | RE: [xsl] Saxon is adding line brea, Michael Kay |
Month |