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