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

This is interesting, and darn close to what I was looking for,
indeed. You are a genious, Dimitre, even if hardly anyone
on this list may be. Where do you keep an archive on your other
generic template work which you seem famous for?

Gunther,

Recently I gave an example of dynamic creation of new functions. It described a
"store" of variables and their values for a calculator. Maybe this could be helpful?

http://aspn.activestate.com/ASPN/Mail/Message/xsl-list/920880

Cheers,
Dimitre Novatchev.

Gunther Schadow <gunther at aurora dot regenstrief dot org> wrote:


Mike Haarman wrote:

There is even a simpler approach using only XSLT: I can make all
templates use an argument that is a constructed node-set
containing name-value pairs (the dynamic environment) and references
to the bindings in this environment would be supported by some
xpath selects in that environment node-set.

Thanks for the insight.  Can the dynamic environment be incorporated into
the internal subset via parameter entities?  Such a solution does not
leave interoperability entirely in crutches.

This is what it would take:

all template calls or applies that typically just look like
this:

<xsl:apply-templates select='...'/>

<xsl:call-template name='...'/>

would have to be transformed into:

<xsl:apply-templates select='...'>
   <xsl:with-param name='environment' select='$environment'/>
</xsl:apply-templates>

<xsl:call-template name='...'>
   <xsl:with-param name='environment' select='$environment'/>
</xsl:call-template>

and every template

<xsl:template ...>
   ...
</xsl:template>

transformed into

<xsl:template ...>
   <xsl:param name='environment' select='/..'>
   ...
</xsl:template>

The environment would be a node set like this:

<foo>bar</foo>
<nick>nack</nick>
<mynodes><bee><bop/></bee></mynodes>
<nick>before nack</nick>

with each name being an element and the value bound to the name
a node-set content of the element.

Adding a binding foo='bar' to the environment would be

...
<xsl:variable name='new-environment-rtf'>
    <xsl:element name='foo'>
      bar
      <xsl:copy-of select='$environment'/>
    </xsl:element>
</xsl:variable>
...
<xsl:apply-templates select='...'>
   <xsl:with-param name='environment'
                   select='msxsl:node-set($new-environment-rtf)'/>
</xsl:apply-templates>
...

Then querying the environment for the binding foo would be:

<xsl:value-of|copy-of|...
      select='$environment/foo[1]'/>

This always picks the first element. This is what does the
shadowing of the old bindings by the new bindings. That's not
strictly necessary, because the old bindings wouldn't have
to be carried along as long as you don't have functional
arguments that depend on old bindings (which I don't see a
way of having in XSLT anyway.) But there is no easy way of
replacing the old bindings that are to be shadowed without
more work, so we can just carry them along.

May be it would be easier to carry the bindings as elements
such as <binding name='foo'>bar</binding> (could be easier
to use with keys or something.) But the principle is the same.

In any event, I don't quite see how parameter entities would
make that much easier. What one would need is macros (ugh)
or just simply an XSLT doing the transforms described above.
In any event, it's a lot of burden to do for routine use
just in case someone wants to have a few dynamically scoped
variables.

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

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

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