Re: Re: local variables as entity reference in differe

Hi Jeni,

Thank you for your answer. And I feel honored to get it from you.
I think I need to give you some context.

As an exercise in xslt, I have made a little application which can turn something like this:
<select name="employees" connection="scott" row="employee">
   <from>emp</from>
   <elements>initcap(ename) name, lower(job) job</elements>
   <attributes>mgr, empno</attributes>
   <foreignKey key="mgr" ref="employees(empno)"/>
   <include name="employees"/>
</select>
into this:
<employees>
<employee empno="7839"><name>King</name><job>president</job>
<employee mgr="7839" empno="7566"><name>Jones</name><job>manager</job>
..
</employee>
...
</employees>

by using msxsl and Oracle sqlplus (hmm, I hope I don't offend Steve by using an MS-Oracle mix)

>I'm surprised that your dummy root element works. Variable definitions
>are only in scope to their following *siblings* and their children - I
>would have thought that having a root element in your entity document
>would mean they weren't in scope for the rest of the template. 

Well, now that I think of it: I'm as surprised as you are! msxsl-bug?

This works:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" >
<xsl:output method="text" encoding="iso-8859-1" />
<xsl:template match="/">
<test> <!-- some root element -->
<xsl:variable name="dummy" select="1"/>
</test>
<xsl:value-of select="$dummy"/> <!-- $dummy is known and output will be 1 -->
</xsl:template>
</xsl:stylesheet>

>Plus of course it means you add a root element to your result tree, which
>probably isn't what you want.

The XSLT-part is used to create sql-scripts, (selects, inserts, updates and deletes) 
which explains why I don't care about result trees: the output method is text.
So the trick here is that the root element is only used to apply the xsl-namespace.

>Personally, I'd think about introducing named templates that are
>shared across the three XSLT documents and collect what you want them

In fact I already make use of your suggestion to call named templates to fill them, by starting of
each stylesheet with an <xsl:include href="templates.xsl"/>. I just thought it would
be shorter and less prone to typing errors to use

<xsl:template match="select" mode="query">
<xsl:param name="some_parameter"/>
&variables; <!--The variables I use are meant to be only in scope within their templates. -->

...
</xsl:template>

in each stylesheet

in stead of

<xsl:template match="select" mode="query">
<xsl:param name="some_parameter"/>
 <xsl:variable name="attributes">
>    <xsl:call-template name="list-attributes" />
>  </xsl:variable>
>  <xsl:variable name="attributevalues">
>    <xsl:call-template name="list-attributevalues" />
>  </xsl:variable>
..
</xsl:template>

>Or perhaps you're pointing to them using a fragment identifier or
>something? Possibly you could declare the name attribute of
>xsl:variable to be an ID attribute and then use #name in entity
>declarations to access the xsl:variables individually.
>

I must confess: this technique is new to me. Well worth studying,
thank you!

Marko.



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