xsl-list
[Top] [All Lists]

Re: [xsl] Only child test

2013-10-14 08:45:18
Hi (please forgive the belated post),

There's also

test="exists(../* except .)"

Plus similar variations on the theme. I think this one translates even
more directly into the requirement as expressed in natural language,
while giving the maintainer a chance to think about exists() and
'except' if need be.

(Yes, I know 'except' can be a little painful -- another reason to
keep in practice with it.)

What an optimizer will do or how it will compare to ".//*[2]" I can't
say -- although I'm also trying to train myself not to care too much
about microseconds except when they are adding up. :-)

Cheers, Wendell

Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^


On Thu, Oct 10, 2013 at 8:22 PM, Peter West <lists(_at_)pbw(_dot_)id(_dot_)au> 
wrote:
It's an endemic problem, and it's multi-layered.  Express this particular 
"atomic" problem more human-understandably, and the problem rises up a level. 
 Computers lack any notion of intention; programmers (hopefully) express 
intention. The most experienced practitioner of a programming language can be 
flummoxed in trying to discern the intention of some piece of code. And 
again, that puzzlement is multi-layered.

None of which is to diminish the vital importance of the principles Ken has 
expressed.

Peter West

"'...neither would they be convinced if someone should rise from the dead.'"

On 11/10/2013, at 12:02 AM, G. Ken Holman 
<gkholman(_at_)CraneSoftwrights(_dot_)com> wrote:

At 2013-10-10 10:02 +0100, Michael Kay wrote:
On 10 Oct 2013, at 09:42, Ð’Ñ Ñ‡ÐµÑ Ð»Ð°Ð² Седов wrote:

can be test="../*[2]" faster?

A processor with a decent optimizer (e.g. Saxon) will do that rewrite for 
you.

What is nice about this optimization is that it leaves decisions about 
execution speed up to the processor and not to the stylesheet writer.

From a maintenance perspective, what you are trying to convey is a test of 
the number of siblings.  I think saying:

  test="count(../*)>1"

... tells the incoming stylesheet maintainer the essence of what is being 
tested, perhaps helping them understand why the test is being done.  If the 
maintainer comes into some code and sees:

  test="../*[2]"

... they might be asking themselves "what is so important about the second 
child?".  It might not be their first thought that "is the current element 
without any siblings?".

Of course this might be obvious in this particular situation to Karl and it 
doesn't matter for his question, but I often will write expressions trying 
to express the essence of the reason for the expression, rather than 
quizzing myself making a contest to find the most compact or the fastest 
running equivalent expression.

Pleasing myself on my (self-perceived) prowess is less important than 
writing code that isn't going to confuse someone being handed my stylesheet 
for maintenance when I'm not around.  I'm a second-generation programmer and 
I well remember such countenance from my father who, in his position writing 
banking software on mainframes, played both roles of having to maintain 
years-old code and writing new code that was guaranteed to be maintained by 
others years later.  One conversation in particular was in 1994 when he was 
modifying decades-old code that was not Y2K aware handling 5-year term 
deposits.

Granted, my customers are in publishing and even with some of the tomes they 
work on the transformations happen infrequently enough that I can rely on 
the skill of the engine writer to make me look good at execution time.  It 
is my responsibility to make me look good at maintenance time.

I hope this helps.

. . . . . . . . Ken


--
Public XSLT, XSL-FO, UBL & code list classes: Melbourne, AU May 2014 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   
mailto:gkholman(_at_)CraneSoftwrights(_dot_)com |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |


--~------------------------------------------------------------------
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>
--~--



--~------------------------------------------------------------------
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>
--~--


--~------------------------------------------------------------------
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>
--~--


<Prev in Thread] Current Thread [Next in Thread>