[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Re: Assignment no, dynamic scoping si (was: Re

Subject: Re: Re: Re: Assignment no, dynamic scoping si (was: Re: RE: Wishes for XSL revisions ...
From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 02 Jan 2002 16:40:27 -0500
dynamic scope examples
Dimitre Novatchev wrote:


Certainly. This is very simple using XSLT. You even don't have to modify the "section" template neither do you need a global variable. In the "paragraph" template declare and use the following local variable:

<xsl:variable name="source" select="ancestor::section[1]/@source"/>

Ouch, I knew you were going to pick this. It works because
I am simplifying my examples. But your approach to this seems
to be a-priori denial of any use for my request (even though it's
documented elsewhere in the literature) and then you pick
the weaknesses of the example to prove the use case non-
substantial. Well, if I were as opposed to this as you are,
I would probably do the same. So, let's drag this out
another round :-)

Your solution works in this case because the source attribute
is *provided*. If it were *computed* from a variety of other
data you could not do that, or at least you would have to
repeat the computation whereever you want to access the value.
According to your own statements, Dimitre, the use of a variable
is in reducing redundant computations of the same value.

So, let's say I need a 'text-indent' value for use in a
plain-text formatter. The value of text indent is calculated
from the cureent indent + an increment that depends on the
element. The template that emits one line of text has no
clue about the algorithm to derive the text-indent from
the structure of the document, that's what the other
templates for the other elements are for.

Or let's say we have 'text-color', that is computed from all
kinds of circumstances, with the logic of computing this being
coded locally in the template that handles the given element.


In my proposal (submitted under Request for ...) and in this
example, however, you see that implicit parameters are
declared just as explicit parameters in their lexical
scope. So you know exactly what they are (of course their
actual binding will be dynamic.)

If there were any type checking with XSLT (say, if XSLT were
a strongly typed language) the type would be mentioned in
the declaration everywhere and could be validated throughout
the stylesheet at compile-time. So it's safe.

Type-checking many descendents of a node in a tree is much more

difficult than type-checking the formal/actual types in a direct

call/instantiation (which is just a segment compared to the tree

in the former case). As Mike mentioned, most probably this would

be prohibitively more costly than the added value the feature

proposed by you may bring.

Because this feature is structurally just like parameters, meaning
there is no other way of declaring the type of an implicit parameter
or binding a value to implicit parameters than to explicit parameters,
why should it be any harder to implement type checking? You can do
type checking just as in statically scoped variables and parameters,
there's no difference.

I'm still not sure how that is a problem with XSLT, because XSLT
doesn't do type checking to parameters either, but I'll follow
your thought nevertheless (which is what I would expect from you

Well, O.K. as I'm working with your concern (the way I expect
you to work with mine), I find that since the call graph is
usually not known statically (can be done to an extent, but most
compilers don't) you will not be able to check for which type
is passed to an implicit parameter in every case. Since you
don't know who calls whom eventually, you will have to make some
simplification. For example, substituting a specialization to
a formal parameter of a generalization type will be a problem
because the two templates could have been called in the reverse
order (through intermediaries) at which point a generalization
would be substituted for its specialization, which would be
invalid. The solution would be to require all of the implicit
parameters to be of an identical type.

Of course this is only a concern if you actually do compile time
type checking and if you cannot afford run time type checking.
Which one is used in XSLT? Isn't it run time type checking?
In that case there is no problem.

It's so easy to implement. Just do shallow binding, associate a
stack of values with the name as an implicit parameter. Then as
you encounter a new binding, push it onto that stack. As you
leave a frame that has made such fluid binding pop it from the
stack. To denote an implicit parameter get it from the top of the
stack. If the type of the value doesn't conform to the declaration
of the implicit parameter (where would a type declaration happen
in XSLT?) you would throw an exception. For statically provable
correctness just do not allow gen/spec substitution. If you find
shallow binding too burdensome, do some deep binding of all
implicit parameters on one association list. That's even easier
especially when dealing with functional arguments (which don't
exist in XSLT either.)

So, what was the problem?

Actually, until now you haven't been

able to provide a single example, where such added value is


You have been given three forms of this use case plus reference to the literature (implicit parameter paper). But so far you're approach to the argument has been to reduce everything that does not support your point of view to it's nearest convenient flaw to shrug it off. You did that with what I said, what Terje said, you even did it with the implicit parameter paper. It's not exactly a gratifying experience to discuss with you. Am I ad hominem? Frustrated, yes, may be I should pause a bit. I moved this to xsl-editors anyway, and the response I got so far is not as frustrating. Interestingly I learned that the dynamic scope issue had never come up in the past, so it isn't pre-decided in any way.


-- Gunther Schadow, M.D., Ph.D. gschadow@xxxxxxxxxxxxxxx Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistant Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.