[xsl] Re: Assignment no, dynamic scoping si

[terje at in-progress dot com (Terje Norderhaug)]

At 8:25 AM 1/4/02, Dimitre Novatchev wrote:
> terje at in-progress dot com (Terje Norderhaug) wrote:
>> At 6:49 PM 1/2/02, Dimitre Novatchev wrote:
>> >Gunther Schadow <gunther at aurora dot regenstrief dot org> wrote: [...]
>>> >> 
>> >> This template would only touch the section and paragraph elements
>> >> of bigbucksbooks and would leave everything else untouched.
>> >> The implicit parameter source is bound to the @source value given
>> >> in the document for everything nested within that section. Now,
>> >> most of this stuff doesn't care, until we get down to the paragraph
>> >> element that now has this implicit parameter available no matter
>> >> how many things were passed through.
>> >> 
>> >> I cannot see how to do that with global variables as you suggest,
>> >> because that book contains many sections and needs to switch
>> >> between the different sources all the time per each section.
>> >> 
>> >> I can see how one can do the same thing with explicit parameters,
>> >> which however, requires modifying all of bigbucksbooks templates
>> >> for table, list (and then: frame, box, float, imagetitle,
>> >> rotated-text, ...).
>> >> 
>> >> So, if you could show me how this can be done without changing the
>> >> whole thing, I am all ears.
>> >
>> >Certainly. This is very simple using XSLT. You even don't have to modify the
>> >"section" template neither do you need a global variable.

Nor *can* you do it with a global variable. You fail to answer Gunther's point that a global variable cannot always do as you suggest (replace use of dynamic variables). I take this as support for that using a global variable only provides a solution for special cases where dynamic variables provide a general solution.

>> >In the "paragraph" template declare and use the following local variable:
>> >
>> ><xsl:variable name="source" select="ancestor::section[1]/@source"/>
>> 
>> 1. This assumes that you know certain constraints about the document, such as that
>> a section never contains a section. Without  this constraint, a template such as
>> below in the imported document would make your work-around unreliable as
>> ancestor::section[1] might give the wrong element in the paragraph template:
>> 
>> <xsl:template match='section//section'>
>>    <xsl:apply-templates/>
>> </xsl:template>
>
>Yes, using implicit parameters without knowing the exact structure of the document
>is literally meaningless, as your example proves it:

This is not what the example set out to prove. It argues that your suggested substitute for the functionality of a dynamic variable is dependent on knowledge about the document structure. Your local variable won't always provide the same value as the dynamic variable it is supposed to replace. Thus you cannot in general substitute the functionality of a dynamic variable with a local variable binding like you suggested.

>In case a paragraph was contained in two "section"s, then the settings for the
>implicit parameter "source" in the outer "section" are overlayed/shadowed by those
>in the innermost (closest) "section" containing the paragraph.

No, you are wrong. The innermost section won't bind the dynamic variable 'source' as it matches the 'section//section' template above. 

>So, while ancestor::section[1] will still access the current value of the implicit
>parameter "source", all previous values set by outer "section"s would be lost. 

Having innermost binding shadow the outmost binding is often desired functionality when using dynamic variables. Just as it is desirable that local variables shadow global variables. I assume you don't want to question the usefulness of that. In both cases one can get access to outmost bindings through renaming.

>What is the meaning of not knowing which parameters will actually reach the recepient?

It would be well defined that it is the innermost binding that counts.

>Clearly this is confusing at best and a debugging nightmare. As David Carlisle very
>well explained, this will result if "dynamic scoping" is artificially supplanted
>into XSLT. Artificially, because the programming model supported by XSLT (control by
>matching input as opposed to control by call) is very, very different from a
>programming model in which dynamic scoping might be more appropriate.

Obviously a processing model not more different than that xsl:apply-templates accepts arguments. I disagree with the notion that processing based on input matching is so different that dynamic scoping isn't appropriate.

XSLT already provides a form of implicit parameters to templates, namely the current node and related context. Imagine the language if these had to be explictely passed. Evidently dynamic binding can be used to make programs easier to understand.

>> 2. The work-around may fail if any xsl:apply-templates instructions in the
>> imported
>> stylesheet selects nodes outside the descendants of the 'section' element. If so,
>> you have no guarantee that ancestor::section[1] will give you the section element
>> that was the current node for a 'section' template earlier in the call chain.
>
>This contradicts the concrete example given -- if the current node was changed by
>some template, so that as a result the reached "paragraph" no longer belonged to the
>same "section", then the value of the implicit parameter will be processed as
>specified by the original "section"-matching template and will produce a false
>result -- the "paragraph", which does not belong to the "section" that specified its
>"source" will be rendered using the colour matching that section's source.

Likely you would want the paragraph to be rendered in a way consistent with the current result tree whether or not it is found inside the "section" that matches the template. Using dynamic variables to bind an environment supports this nicely. Binding local variables as you suggested don't, making the rendering instead depend on the element location in the source document.

>This shows once again that using implicit parameters would be unreliable in cases
>like the one you describe.

Unrealiable in this context means that your work-around using local variables doesn't always provide the same value as the dynamic variable they are meant to substitute. This means that your local variables cannot provide an unconditional substitute for dynamic binding. Case closed.

>> 3. If the 'section' template contains two xsl:apply-templates where each pass on a
>> different value for the dynamic variable $source (or another template binds the
>> variable) the 'paragraph' template might be instantiated with different values for
>> $source. The same value might be impossible to calculate from the current context
>> in
>> the 'paragraph' template, e.g.:
>> 
>> <xsl:template match='section'>
>>     <xsl:apply-templates>
>>       <xsl:with-implicit-param name='source' select='@source'/>
>>     </xsl:apply-templates>
>>     <xsl:apply-templates>
>>       <xsl:with-implicit-param name='source' select='"default"'/>
>>     </xsl:apply-templates>
>>  </xsl:template>  
>
>This seems to be the first example from four or five in a row, that may show some
>value of using implicit parameters. 
>
>Once again, this demonstrates an attempt to mix two utterly different programming
>models. xsl:apply-templates is not at all similar to xsl:call-templates. 

If so, would you argue that xsl:apply-templates shouldn't allow parameters? That seem to be the conclusion, as implicit parameters work as a convenience to explicit argument passing. 

>I cannot better than David Carlisle explain the consequences of mixing the two
>programming models:
>
>"Unlike some other more traditional languages, in XSLT the calling order
>of the templates is not at all explict in the program source and is
>driven by whatever document is passed in as data.  This means that
>normally templates need to be written to work wherever they happen to
>match and _without_ regard to the particular calling sequence that
>caused them to fire. Dynamic scope would radically change that and mean
>that the behaviour of a template would much more directly depend on the
>stack of "currently active" templates. It is not at all clear to me that
>this would make XSLT an easier language to understand or work with.

The alternative to dynamic variables would be to explicitely declare and pass the values as arguments in the templates. If all arguments are explicitely declared and passed, the behavior of a template would just as much directly depend on the stack of "currently active" templates as if implicit parameters were used. 

>At present any dependency on previously called templates is (a) rare and
>(b) explictly flagged by the declaration and passing or parameters.
>This is a good thing (I believe) Of course the fact that the syntax for
>passing parameters is so verbose (even by XSL standards) means that it
>is sometimes a pain, but there have been some "syntactic sugar"
>proposals to help with that without changing the underlying execution
>model".

The problem is that using explicit parameter definitions and passing causes dependencies between importing and imported stylesheets that may require duplicated/redundant code with associated problems. Dynamic binding solves this without making a template more dependent on "currently active" templates.

>> 4. Replicating the same xpath expression in each template that want to use the
>> $source isn't exactly good practive with respect to writing maintainable code. 
>
> The code will be more maintainable, if it is exactly known what nodeset/value is
>being accessed than having to guess exactly which of the possibly many overlaying
>definitions of an implicit parameter successfully made it through.

There are cases where you may want local control, but others where the control is better handeled elsewhere. Just like you sometimes may prefer to use a global variable instead of a local one. The local template would of course not have to guess but just use the innermost binding of a dynamic variable.

>> Nor does it facilitate efficient execution. 
>
>This is not obvious at all. The time to evaluate an XPath expression is the same
>regardless whether the evaluation was done by the caller or the callee. 

This is wrong. It is obviosly faster to get the value of "@source" relative to the current node than to get the same using "ancestor::section[1]/@source" relative to a descendant. In addition, binding the result to a dynamic variable once for each section would likely be faster than navigate the document tree and binding a variable for each paragraph in the section. 

>In fact the
>necessity to maintain the stack (push and pop from it, and also the increased memory
>it requires) will probably make passing implicit parameters less efficient.

This looks like an argument against using variables in general. Dynamic variables can be implemented quite efficient. Besides, what is suggested is an optional feature,meaning that the feature doesn't have to have consequences for those that don't use it.

>> In conclusion, dynamic variables provide a general solution to problems that
>> work-arounds only can solve in special cases with great dependency on document
>> constraints and assumptions about the imported stylesheet. 
>
>As I hope the reasoning above have made quite clear, there isn't good justification
>for such conclusions in the case of pushing forward for dynamic variables in XSLT.

Most of your arguments deliberately avoids answering the limitations I have pointed out regarding your suggested substitutes for the functionality of dynamic variables. Instead, you jump to question the use of dynamic variables in itself.  I take this as evidence that you accept that dynamic variables provides functionality not currently available in XSLT. I appreciate if you can verify that this is the case so that we can move on to other issues, such as technical challenges and usability considerations.


-- Terje <terje@in-progress.com> | Media Design in*Progress 
   Software for Mac Web Professionals at <http://www.in-progress.com>
   Take Advantage of Server Side XML and XSL with Interaction 3.6!



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