Re: [xsl] Re: Assignment no, dynamic scoping si (was: Wishes for XSL revisions ...

[Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>]

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.

regards
-Gunther



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