RE: [xsl] recursive sorting by element name -> Xalan Issue

Subject: RE: [xsl] recursive sorting by element name -> Xalan Issue
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 29 Nov 2007 18:32:14 -0500
Scott,

At 05:55 PM 11/29/2007, you wrote:
There we go. Thanks for the clarification, Wendell. I had it ingrained
into my head somewhere never to use self:: for attributes, but I
couldn't quite remember why. The specific self::@attr syntax was the
part I forgot, and couldn't find quickly before I sent my response. Just
to check then, the self:: axis means, absolutely and always, the axis
that the current node exists in? I suppose that's a redundant statement,
now that I think about it.

Yes, but with the complication that when things are named or the wildcard "*" is used, self:: always calls for an element, so that self::div always looks for an element named div, and never an attribute.


Remember that XPath node tests (the part that comes after the axis) include such rare birds as "processing-instruction()" and "comment()" as well as "node()" and "*" and let's not forget "text()". This makes these questions of what type of thing you're looking at (or for) bit murky, since the relevant rules involve both the node test, and the axis on which the nodes are found to be tested. (XPath 2.0 has node tests "element()" and "attribute()", which helps by rounding out the set.)

Aside: "@text()" is my candidate for obscure XPaths guaranteed to return an empty node set, for reasons that may now be clear.

 Correct me if I'm wrong then; what I should
have ingrained into my head now regarding the self:: axis is that I
should remember to carefully monitor my usage of common abbreviations
directly afterward. (Or just continue using only the verbose syntax
until the end of the step.) I think that's clear enough to remember
accurately.

That would work; or just remember that "@" abbreviates "attribute::", so since "self::attribute::" makes no sense, neither will "self::@".


> BTW, if you wanted to write for clarity, "+not(@about)" could be
> expressed "number(not(@about))", or if you preferred you could rely
> on what Mike reminded us, that false() sorts before true(), and
> simply say "not(@about)" or "boolean(@about)" depending on which way
> you need it to sort.

number() would be clearer, for sure. I commented on the clarity near the
end of my reply because I was shooting for absolute brevity, and while
+not() was the shortest syntax in the end, I felt it might have been a
little extreme, cutting into the clarity of the code. As Michael pointed
out, there are several other angles you could use (data-type, order) to
get the same results, but none with syntax as razor-slim as mine. :)
Besides the boolean sort-order, that is; I didn't know that before. It
seems like a rather happens-to-work situation, but since it happens to
work, then viva, I'll definitely remember it. :)

Indeed. It's an obscure enough area that whatever form of elegance you prefer, you'll be doing someone a favor to include a comment explaining what it does. (Or by not doing so, if you know for a fact that they prefer puzzles.)


Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread