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

[xsl] Sequential numbers in pure xslt, breaking the no-side-effect rule

---

---

Hi XSLT'ers,

AFAIK the answer to this is a simple, short "no, cannot be done". But I wanted to check it with the specialists to be sure ;)

The request is simple: create a function that returns '1' on first call, and returns one higher each next call, without overlaps or jumps, without any input. Let's call it my:seq-number:

<xsl:function name="my:seq-number" as="xs:integer">
   <!-- some implementation -->
</xsl:function>

then the following line would return '1 2 3':
<xsl:value-of select="my:seq-number(), my:seq-number(), my:seq-number()" />

There are three scenarios to resolve this issue:

 1. Use an extension function in the host language (java, .net)
 2. Use an extension instruction like saxon:assign
 3. Use 'hidden features' of generate-id().

The first two are obvious. The last one is the best I good get with "pure xslt", but as I tested, does not work with AltovaXML (in fact, it is not even guaranteed to work on other or future versions of Saxon):

<xsl:function name="my:seq:number" as="xs:integer">
<xsl:variable name="node"><xsl:comment /></xsl:variable>
<xsl:sequence select="xs:integer(substring(generate-id($node), 2) - 1" />
</xsl:function>

this will indeed return 1,2,3 etc, provided that, depending on the order of execution, the first node that is auto-created is this node, and that no other nodes are created meanwhile. (FYI, Saxon numbers document nodes as d1, d2 etc, where 'd1' is the input doc).

Doing this with AltovaXML generates too much randomness, i.e., the output of generate-id is: idroot219951944 idroot219959376 etc (this is not a non-comformance bug. Not being able to deal with empty <xsl:comment /> is, however, but I am getting adrift...).

Am I overlooking something, or is this about the best I can get? I know I am in violation and that requesting for functions/variables/templates that return different results with the same input is asking for breaking the rules.

Thanks for any extra insights on an already overly discussed subject,

Cheers,
-- Abel Braaksma

---