RE: functions and sequences

> I've also run into this issue.

Yes, it's a common experience. We've made a few changes in the latest draft
to alleviate some of the problems - specifically, adjustments to the rules
on when whitespace gets added as a separator.
> 
> While it is perfectly understandable, it is a major change from
> XSLT/XPath 1.0 where it was not allowed to have two immediate
> text-node siblings.

It still isn't allowed to have two adjacent text-node siblings! The real
problem is that when people write

<xsl:text>A</xsl:text>
<xsl:text>B</xsl:text>

they are accustomed to think in terms of creating text nodes that are
children of an element, and which are therefore immediately concatenated.
But if you aren't creating an element at the time, you are creating a
sequence of two text nodes, which aren't siblings of each other, and which
can therefore exist quite independently.

> I think it would be good to support the following in order to avoid
> inconvenience and confusion:
> 
>    -  Allow an xs:string() constructor, which takes a sequence of
> xs:strings or a sequence of text nodes; This will allow a function of
> type xs:string to automatically convert a sequence of
> strings/text-nodes to a single string return value.
> 
>    - Provide an overload of the concat() function, which takes a
> single argument of type sequence of xs:string or sequence of text
> nodes.

This operation can already be done conveniently using the <xsl:value-of>
instruction in XSLT, or the string-join() function in XPath.

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