At 2006-07-12 12:52 -0400, Steve wrote:
Forgive me for the tangent, especially if it sounds
ignorant, but as a
newbie to XSL I have a hard time understanding the benefit
in not being
able to redefine a variable. While I do not doubt the talent and
genius that went into the above examples and speculations, I can't
imagine a benefit that outweighs the time economics involved
up with the above solutions, versus simply doing a $variable =
$variable - $x and being done with it in 10ish lines.
As it happens there was a paper at the XIME-P XQuery conference last week
proposing procedural extensions to XQuery, including variable assignment.
The paper is significant because of the influence of its authors:
One could of course do the same thing for XSLT.
I have considerable reservations about the proposal. Although it's a cleaner
solution than saxon:assign, which has never had very well-defined semantics,
I fear that it's likely to have the same drawback, namely that users who
haven't been exposed to declarative programming will use it as their first
choice rather than as a last resort, which means they won't get the benefits
of using a language that is primarily declarative.
I feel the situation is very similar to the introduction of goto-less
programming in the 1970s. COBOL and Fortran programmers found it very hard
at first to see how they could write code without a GOTO statement.
Eventually they were forced to learn, and they became better programmers as
a result. It does mean there is a steeper learning curve, but at the top of
it there are broad sunlit uplands!
I think the right solution architecturally is to use a procedural pipeline
processing language which defines the overall control flow of an
application, and which invokes purely functional queries and transformations
written in XSLT or XQuery. For problems like the one in this post, I think
recursive solutions are quite adequate: it takes a while to get the hang of
them, but they're not difficult once the idea is mastered.
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>