[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] xsl:sort descending causes attribute nodes to be created after children, causing an error

---

---

Michael Kay wrote:

For attribute nodes the value of the sort key (child::text()) will always be
an empty sequence. An empty sequence sorts before any other value, so in
descending order it sorts last, and since the template with match="@*"
creates attribute nodes, you will be adding attributes to the parent after
the children, which is an error.

Indeed, I was wondering two things: why xsl:sort could mess up with the attributes and why the text() did not work for the attribute. But I forgot that the attribute axis never has any children....

This behaviour is certainly correct, and I'm not sure which part of it you
are questioning.

Well, somehow I hoped that sorting attribute nodes would be a no-op, causing them to appear in the input node's order. It makes sense, I think, considering that ordering attribute nodes does not makes sense: the order of attributes is undefined.

But thinking of this again, makes me realize that this is of course a very wrong way of looking at it. I am sorting the nodes and manipulate them after sorting. Surely, sorting attribute nodes makes sense, esp. when you do something else with them then mere copying, where the order can be important (i.e. for attributes-to-xml-elements for instance, or to text output).

Incidentally, if any of your child elements contains an embedded comment,
the sort will fail because text() selects more than one node, and it's an
error in 2.0 for the sort key to be a sequence longer than one (in 1.0 all
but the first are ignored).

Just checked the original project. I appear to do it correctly there (selecting a single node). I just oversimplified a bit ;-)

Cheers,
-- Abel

---