I wonder what the reason is for merging adjacent text nodes? Other
than compacting the a tree a little, what purpose does it serve?
imagine if (as some early implementations did) xslt engines were able to
reflect an underlying DOM built from some sax parse that had arbitrarily
chunked large text streams.
given
<foo>qwertyuiopasdfghjklzxcvbnm</foo>
foo/text()[1]
would return q or qwert or qwertyuiopasdfghjklzxcvbnm depending on how
many adjacent text nodes there are, and what was in the first chunk.
Rather than let the user worry about that, xpath forces the implementor
to worry about it and foo/text()[1] has to return the whole thing no
matter how many text nodes may be in an underlying DOM.
Of course the timing is rather more subtle in xslt2 (or xslt1+node-set)
because you can query into variables and detect whether the merging has
happened yet for constructed nodes, whereas in pure xslt 1, it's really
only an input source issue as you can't query into constructed text
nodes so can't tell if they are merged or not.
David
________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________
--~------------------------------------------------------------------
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>
--~--