> Any estimate on the Sorted Iterator issue ?? I tested the SQL
> code, it is still there.
I've been racking my brain on this. I'm still not quite ready to make a
fix. Sometime this coming week, I hope (though I'm not sure I have a good
plan quite yet...).
> The second question is related to the other problem with variable
> testing. it seems that the root problem was that I am creating a
> variable by possibly assigning it the same variable in a for-each
> loop using a choose statement. Its not as complicated as it sounds,
> see previous sample. Its all about the ability to mutate variables,
> Xalan (DOM mode) allowed it. Now in a single instance, it is not
> being allowed. The big questions is, are we closing all the loopholes
> if so I have a bigger problem. If not should we make it work the same
> for all cases ??
I'm not sure I understand the question. In the example given, the variable
access is being done inside the definition of that variable. This is
definately not allowed. I just checked in a fix that gives you hopefully a
reasonable error message ("Variable accessed before it is bound!"). From
the recommendation: "xsl:variable is allowed anywhere within a template
that an instruction is allowed. In this case, the binding is visible for
all following siblings and their descendants. Note that the binding is not
visible for the xsl:variable element itself. xsl:param is allowed as a
child at the beginning of an xsl:template element. In this context, the
binding is visible for all following siblings and their descendants. Note
that the binding is not visible for the xsl:param element itself."
(http://www.w3.org/TR/xslt#local-variables).
There is another error in the stylesheet that Xalan or XT does not catch,
though Saxon does: "A binding shadows another binding if the binding occurs
at a point where the other binding is visible, and the bindings have the
same name. It is an error if a binding established by an xsl:variable or
xsl:param element within a template shadows another binding established by
an xsl:variable or xsl:param element also within the template. It is not an
error if a binding established by an xsl:variable or xsl:param element in a
template shadows another binding established by an xsl:variable or
xsl:param top-level element." So Saxon throws a "Error at xsl:variable on
line 6 of file:/E:/xml-xalan/test/tests/conf/x.xsl:
Variable is already declared in this template" error. So I'm going to
keep the bug open for a bit until we fix this, i.e. throw an error.
But I'm still not sure about "If not should we make it work the same for
all cases ??".
> Its all about the ability to mutate variables,
> Xalan (DOM mode) allowed it.
Variables can not be mutated in XSLT. If this was ever allowed, it was a
bug.
-scott
