Re: Again: Incrementing variables

Subject: Re: Again: Incrementing variables
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 06 Sep 2000 17:21:56 +0100
Jeorg,

What you're describing verges on the practice of recursive named templates,
which is a form of looping that XSLT does support, and that is widely
practiced to solve certain kinds of problems. All of this interesting
ground has been gone over before (see the FAQ, Mike Kay's book etc.), which
is one reason the veterans on the list may not be giving this the attention
it may seem to deserve (i.e., it's because they already have).

Mike Kay's commentaries, plus a number of interesting posts in the archive
etc., may explain more. For various less-than-fully-explicit reasons, XSLT
is intended to be "side-effect free", and largely succeeds at it (thus
variables are scoped). Yet when you look in detail at the kinds of problems
that people usually grab at a for/next loop to deal with, it turns out that
almost all the time, there's a perfectly elegant (albeit sometimes verbose)
way in XSLT to do it.

Now admittedly, your use case appears to be somewhat out of the mainstream;
but if people were to see the code and exactly why you need a 'variable' in
the procedural sense, they might surprise you.

But note particularly what XSLT 11.5 says:
  "A binding -shadows- another binding if the binding occurs at a point
where the other binding is visible, and the bindings have the same name. It
is an error if a binding established by an xsl:variable or xsl:param
element within a template shadows another binding established ... also
within the template.

  "... XSLT does not provide an equivalent to the java assignment operator
... because this would make it harder to create an implementation that
processes a document other than in a batch-like way, starting at the
beginning and continuing through to the end."

Regards,
Wendell

At 02:40 PM 9/6/00 EDT, you wrote:
>Messieurs,
>
>   thanks for all the responses which, however, weren't really too
>helpful despite their references to dungeons, dragons, and the like
>and despite the different alternative names for xsl:variable. ;-)
>I found a solution for my problem - I had some other bug in my
>code. Once I got rid off that it actually turned out I
>can treat xsl:variables as... well, variables. In particular, I 
>can write
><xsl:variable name="var" select="1"/> and then
><xsl:variable name="var" select="$var + 1"/>
>But before I get lynched here I better stop my heresy. Anyway, if
>this forum accepts suggestions for improvements for xslt, then
>let me suggest to add "proper" variables to xslt - for the sake
>of all those freaks (like me) who simply forget to think in terms
>of scopes all the time. ;-)
>
>- Joerg
>Dr. Joerg M. Colberg
>Econovo Software, Inc.
>joerg.colberg@xxxxxxxxxxx
>
>PS: The reason why I was dealing with all that stuff is the
>    following: I want to process two branches of an xml tree
>    at the same time. Both branches are isomorphic in their
>    structure. One branch contains data, the other one contains
>    processing information. I loop over the processing information
>    (which defines my output in the broadest sense) and use
>    "variables" to jump across the data branch. The reason for
>    this weird stuff was that I wrote an xsl which generates an
>    xsl from html. :-)
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>

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


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread