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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Limitation of <xsl:result, Michael Kay | Thread | RE: [xsl] Limitation of <xsl:result, Michael Kay |
[xsl] format number question, JWALLIS | Date | RE: [xsl] Saxon is adding line brea, Martinez, Brian |
Month |