atom feed6 messages in com.mulberrytech.lists.xsl-listRE: [xsl] XPath element constructor
FromSent OnAttachments
Jakub MalýAug 28, 2012 1:54 pm 
G. Ken HolmanAug 28, 2012 2:02 pm 
Imsieke, Gerrit, le-texAug 28, 2012 2:03 pm 
Liam R E QuinAug 28, 2012 2:17 pm 
Michael KayAug 28, 2012 3:28 pm 
Jakub MalýAug 29, 2012 5:06 am 
Subject:RE: [xsl] XPath element constructor
From:Jakub Malý (
Date:Aug 29, 2012 5:06:59 am

I hope to answer the responses I've got so far:

I deliberately used the most trivial example, which itself does not look very useful and can be replaced by other XSLT code - I am aware of that.

I am generating my code -- and I am generating XPath expressions. Certain cases require to generate expressions that create elements. The complexity of the algorithm would increase significantly if I would generate a combination of XPath and XSLT instructions, so that is not the way I want to go. Generating "constructor" functions is the most transparent solution I have found so far, but not very nice (and I want the code to be as transparent as possible, even though it is generated).

It has been pointed out by several people, that XSLT is in fact a mangle of two languages and XPath in XSLT has its specifics. It is e.g. possible to create items that are not part of standard XPath (e.g. maps). Maybe the limitation around element constructors in XPath could be lifted as well. As Michael have written, often there are XPath and XSLT ways to do the essentially same thing (if/then/else vs. choose/when, for-each vs. for .. in .. return). Elements are routinely created in XSLT and the new elements can be used in XPath (through variables). Elements can even be created in XPath expressions through calling XSLT functions. Only, they cannot be created in XPath directly due to the syntax limitations.

(this is just thinking, I am not saying that XPath or XSLT or wrong or incomplete).

-----Original Message----- From: Michael Kay [] Sent: Wednesday, August 29, 2012 12:29 AM To: Subject: Re: [xsl] XPath element constructor

This relates to two of the distinguishing characteristics of XSLT, which are closely related:

(a) it's a two-language system: XPath is embedded in XSLT, and as such the combination isn't fully orthogonal (the embedding only works one way; to invoke XSLT logic from XPath you have to go via functions or variables)

(b) XSLT is an XML vocabulary, which means it can't play the kind of games that XQuery plays, for example by allowing elements to be nested within attributes.

These characteristics of XSLT of course have significant benefits, which are presumably familiar to regulars on this list, but they also have drawbacks.

On 28/08/2012 21:55, Jakub Malý wrote:

Hi, lets say, that somewhere in an XSLT context, I want to do this:

<xsl:sequence select="<my-cool-element>foo</m-cool-element>" />

But that is too insane, so I rewrite it like this:

<xsl:sequence select="element my-cool-element { 'foo' }" />

Only if constructors were supported in XPath. But I CAN create new nodes in XSLT context! So I end up with:

<xsl:function name="my:const-my-cool-element" as="element()"> <const-my-cool-element>foo</const-my-cool-element> </xsl:function> . <xsl:sequence select="my:const-my-cool-element()" />

Yay :( There is no question, really.