Re: The evaluate function

Mike:
>> Some relates to other issues concerned with static typing: we are
>> generally trying to move towards having as much type information as
>> possible available statically, and a crude evaluate() function takes
>> us in the opposite direction.
>

Jeni:
>Much as I hate to suggest it, you could always use a keyword instead:
>
>  "evaluate" StrExpr "as" Datatype
>
>where StrExpr is an expression that is cast to a string and Datatype
>is a data type as in Production 43 in the XPath 2.0 WD.

The type of the expression isn't the biggest problem.

Suppose I have a global variable:

<xsl:variable name="x">
   <something quite complicated >
</xsl:variable>

Now, if a clever XSLT processor sees that $x is only ever used in
contexts where it is coerced to a string (e.g. in xsl:value-of) it can
store only the string value and throw away the original tree fragment,
saving memory and processing time.  It might even calculate the string
value directly without a tree at all.

But as soon as we  allow a general evaluate function, if the transform
uses just one evaluate we can no longer do the above optimisation (and
many others), because we cannot guarantee that some day the expression
won't evaluate to something that uses $x as a node-set.

This has the nasty side-effect that it makes performance very
unstable.  You suddenly find a transform runs orders of magnitude
slower just because of the introduction of a single evaluate() in some
dark corner of an imported transform that rarely gets executed anyway.

>> Some is a concern about principles: how do we cater for implementors
>> who want to compile stylesheets into compact executable code and
>> ship that code for execution on handheld devices?
>
>Make it optional? Or partially optional if there's a subset of
>expressions that these implementers could handle.

For my money, the status quo is fine: if you want evaluate(), use a
proprietary extension.  If we can get enough vendors to agree what the
rules regarding variable references and such should be, to the point
we get several common implementations under the EXSLT umbrella, then
that is the time to think about putting it in the standard (probably
as an option for the reasons Mike says).  Until then, please leave
well alone.

Regards,
Trevor Nash
--
Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@xxxxxxxxxxxxx

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