David Carlisle wrote:
yes that's the expected behaviour (although of course it's nothing
really to do with the xsl:sort, a more direct case is
<x>
hello
<xsl:attribute name="x"/>
I knew that it wasn't allowed explicitly. However, in the example I
gave, the child nodes of the rows-node are ordered based on their text()
child. I realize now that this never selects anything on the attribute
axis (having no children) and thus returns an empty sequence, which ends
up at the start of the ascending sort (which causes no problems).
Reversing the sort places it at the end, causing the error.
sounds all in all quite logical eventually.
It's required to allow an implemenation to start serialising the result
tree before processing is finished. If you were allowed to generate an
entire document then generate a version="2" attribute as the last node
before closing teh document element, the processor would always haveto
buffer the entire result tree in memory just in case the system did
this.
Thanks for this explanation. I often wonder the "why" behind a given
feature of the spec, this makes it sound so more plausible.
Cheers,
-- Abel Braaksma
--~------------------------------------------------------------------
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>
--~--