server side xalan / struts has non-standard xslt 1.0

Hi,

I'm in a very big project and in one the possible transformation
scenarios there is a behavior that is an error, most probably from
some weird server side/processor configuration. So the question is if
anyone, familiar with either Struts 1.3.8, Xerces 2.9, or Xalan 2.7.1,
has witnessed this sort of behavior in the past or if they can suggest
any sort of reason why it might be going on.

the errors are as follows:

1. there are two templates being called in the transformation context
that are not actually present, this does raise an error but the
transformation continues anyway.
2. When the transform continues anyway there is a template match it
hits that has a structure sort of like this (template simplified to
show underlying problems):

<xsl:template match="a">
<xsl:variable name="id" select="@id"/>
<xsl:variable name="b" select="b"/>
<xsl:variable name="c" select="c"/>
<xsl:variable name="d" select="d"/>

<li>the value of the variable b is <xsl:value-of select="$b"/> and the
xpath is <xsl:value-of select="b"/></li>
<li>the value of the variable c is <xsl:value-of select="$c"/> and the
xpath is <xsl:value-of select="c"/></li>
<li>the value of the variable d is <xsl:value-of select="$d"/> and the
xpath is <xsl:value-of select="d"/></li>

</xsl:template>
given an input like the following (input also simplified to show
underlying problem):

<a id="a">
<b>b</b>
<c>c</c>
<d>d</d>
</a>

then the output is like this

<li>the value of the variable b is a and the xpath is b</li>
<li>the value of the variable c is a and the xpath is c</li>
<li>the value of the variable d is a and the xpath is d</li>

3. If I remove the references to the templates  that do not exist then
the problems go away.

the behavior seems as if somewhere in the server side code there is
logic that says if just this particular transformation fails read in
the xslt to a dom and change all the selects to equal 'a' and then run
it again - sure that would explain the result but it seems pretty
unlikely so I was hoping someone knew of a bug in one of the jars
referenced above that could lead to some sort of similar behavior?
Just checking as we are delivering this week, and I don't have time to
debug a lot of java code

Cheers,
Bryan Rasmussen