Re: [xsl] Only child test

[Wendell Piez <wapiez@xxxxxxxxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>
wrote:
>
>> At 2013-10-10 10:02 +0100, Michael Kay wrote:
>>> On 10 Oct 2013, at 09:42, CbC Cb!CB5C CB;CB0CB2
CB!CB5CB4CB>CB2 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@xxxxxxxxxxxxxxxxxxxx |
>> Google+ profile: https://plus.google.com/116832879756988317389/about |
>> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |