RE: [xsl] A sequence of more than one item is not allowed as the value of item

Subject: RE: [xsl] A sequence of more than one item is not allowed as the value of item
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Thu, 2 Jun 2005 12:25:15 +0100
> Indeed, the key here is that text nodes get merged together at stage 2
> before the atomization at stage 3 - which is why I'm still 
> confused if I
> specify xs:string+ instead of item()+:
> 
> <xsl:variable name="foo" as="xs:string+">
> 	<xsl:text/>abc<xsl:sequence select="'def'"/>
> </xsl:variable>
> 
> <xsl:variable name="foo2" as="xs:string+">
> 	<xsl:text/>abc<xsl:value-of select="'def'"/>
> </xsl:variable>
> 
> 
> <xsl:value-of select="$foo" separator=","/>
> 
> Gives ,abc,def
> 
> <xsl:value-of select="$foo2" separator=","/>
> 
> Gives ,abc,def
> 
> I would have expected the same behaviour as specifying item()+ as
> atomization occurs after the merging of the text nodes in $foo2
> 
> This suggests that by specifying xs:string Saxon is jumping 
> the gun and
> converting the text nodes (zero length text nodes as well - 
> the leading
> comma) to strings before stage 2.

Indeed, it's converting text nodes to strings before it even starts the
"constructing simple content" process. The overall process here is:

1. Construct the value of the variable

   1a. evaluate the sequence constructor, producing a sequence of text nodes
(foo2)
       or a sequence containing a mixture of text nodes and strings (foo)

   1b. apply the "function conversion rules" to convert the result of 1a
       to the required type (xs:string+). This causes text nodes to be
       individually atomized to strings

2. xsl:value-of select="$foo" then invokes the "constructing simple content"
   rules to convert a sequence of text nodes and/or strings to a single text
nodes.
   In both cases the input is a sequence of strings, so the rules for
joining
   adjacent text nodes don't kick in.

It's certainly true that this whole business is going to generate a lot of
questions. We've tried to design the rules so that they are (a) backwards
compatible, and (b) do the "right" thing in common cases. The downside of
this is that the rules are quite complicated, and when they don't do the
obvious thing, it's quite tricky to work out why.

Michael Kay
http://www.saxonica.com/

Current Thread