I think the reason for the confusion here is specifically that two
adjacent text nodes cannot be implicitly cast (or is that atomized?) to
a single string.
The two text nodes are not adjacent in the sense of being siblings, they
are just in the same sequence.
In XSLT1 the nearest thing to a sequence of two text nodes is a node set
of two text nodes.
If the current node has two text node children and you go (in 1.0)
<xsl:variable name="foo" select="text()"/>
<xsl:value-of select="$foo"/>
then you don't get an error you get (just) the first text node, with the
second one being discarded.
Given that, I think it would have been virtually impossible to come up
with any scheme for implictly casting a sequence of text nodes to a
string that did not discard all but the first, which probably wouldn't
have been what you wanted either.
If you can't make a 1.0 construct work in 2.0 it's much better to make
it an error than make it silently do something different.
David
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--