Subject: Re: [xsl] A beef with XSLT Sometimes too complicated From: David Carlisle <davidc@xxxxxxxxx> Date: Fri, 14 Jul 2006 13:41:43 +0100 |
<xsl:variable name="x" select="if $var then select(@id='1') else select (@id='2')"/> <something id="1"> hello! </something> <otherthing> goodbye </otherthing> actually I can't guess what the intended semantics of that are. I can guess you mean to define $x to be one of those elements, but where would control flow after the xsl:variable? On the face of it it would produce both the elements in teh result as they are literal result elements. In XSLT2 you can more or less arbitrarily mix xslt and xpath code by way of xslt functions. <xsl:function name="x:f"> <xsl:param name="here"/> <xsl:apply-templates select="$here/a"/> </xsl:function> <xsl:function name="x:g"> <xsl:param name="here"/> <xsl:apply-templates select="$here/b"/> </xsl:function> <xsl:value of select="if (foo) then x:f(.) else x:g(.)"/> obviously the functions can be any xslt construct, template calls, for-each instructions, whatever. This is basically how xq2xml works. As Mike just mentioned XQuery is more naturally compositional than XSLT, you can nest expressions much more freely, so when converting to XSLT, xq2xml is either in xslt mode or xpath mode. If its in xslt mode and needs to generate some xpath, it generates a select=..." attribute and then switches to xpath mode. Conversely if its in xpath mode and needs to generate some xslt (to generate element nodes, or execute xsl:for-each, usually) then it puts all the generated xslt in a function body, and puts the function call in the xpath expression. David
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] A beef with XSLT Sometime, Nic James Ferrier | Thread | [xsl] Passing XML Tree to a java me, Omar Saeed |
Re: [xsl] A beef with XSLT Sometime, David Carlisle | Date | Re: [xsl] A beef with XSLT Sometime, Colin Paul Adams |
Month |