[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] XPath element constructor

Subject: RE: [xsl] XPath element constructor
From: Jakub Malý <jakub@xxxxxxx>
Date: Wed, 29 Aug 2012 14:07:30 +0200

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

-----Original Message-----
From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
Sent: Wednesday, August 29, 2012 12:29 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
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

(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

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

Michael Kay

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.
> Jakub.

Current Thread