Re: value of variable inside a condition doesn't work?

Tobias Reif wrote:
> Mike Brown wrote:
> 
> > [...] <x><y/></x>. <y/> can be written as <xsl:foo/>
> 
> 
> Could you elaborate?

If y = f(z), then the inverse is true: f(z) = y.
If x also equals y, then x = f(z), and f(z) = x.

The equality expressions above are all just assertions of identity and of the
relationships between variables. They are just statements of fact. "If f(z)
were evaluated, it would be y. In other words, f(z) *is* y."  This is entirely
different than saying "You, you there with the finger in your ear! Evaluate
f(z) and tell me what you get! What's that? It's y? Ah, thank you very much!
I never would have known!"

OK, so now consider that <x><y/></x> is the XML equivalent of x = y.  It is
declaring an immediate relationship between thing x and thing y. When in a
template in your stylesheet, it is a declaration that the result tree contains
an element x which contains empty element y.

If the evaluation of <ext:foo/> would produce a node-set containing an empty
'y' element, then

<x><ext:foo/></x>  =  <x><y/></x>

...you could write one or the other and it would mean exactly the same thing.

The XSLT processor can, in theory, know this, and can optimize accordingly,
remembering that <ext:foo/> is <y/> and shortcutting the evaluation after the
first time, just using <y/> whenever it sees <ext:foo/> and all other factors
that would influence how it is evaluated (including what XSLT calls the
context) are the same.

This also applies perhaps a little more concretely to functions in an XPath
expression. The XPath engine is free to optimize by remembering that function
foo() is a certain object, as long as it is called with the same arguments.

So if you were counting on <ext:foo/> sometimes being <y/>, sometimes <z/>,
and foo() sometimes being 'bar', sometimes 'baz', then you might be surprised
when an XSLT processor chooses go through the motions of evaluating <ext:foo/>
and foo() only once during the transformation.

Mike

-- 
  Mike J. Brown   |  http://skew.org/~mike/resume/
  Denver, CO, USA |  http://skew.org/xml/

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