[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Scott,
At 05:55 PM 11/29/2007, you wrote:
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.
That would work; or just remember that "@" abbreviates "attribute::", so since "self::attribute::" makes no sense, neither will "self::@".
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.)
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] recursive sorting by elem, Scott Trenda | Thread | RE: [xsl] recursive sorting by elem, Scott Trenda |
Re: [xsl] How to read Schema XSD in, Abel Braaksma | Date | [xsl] MarkMail now archiving xsl-li, Jason Hunter |
Month |