I think, that the new xsl:evaluate instruction is the most
harmful addition, as it either rules out the idea of
compilation of xslt in native/IL/other language code, or
demands for interpreter or compiler to be available at
stylesheet execution time.
This makes execution environment much more heavier than necessary.
You may have noticed we have an open issue (issue 13) saying that we have
not yet decided whether this will be a mandatory or optional feature of the
language. The main argument for making it optional is to allow stylesheet
execution in run-time environments where having an XPath compiler would be
But probably the worst effect will be from developers who
will widely practice the "easiest" way to achieve desired
effect with dynamic xpath.
There are many use cases for dynamic evaluation; it is one of the most
widely-used and widely-implemented extensions in existing XSLT processors,
and it seems reasonable to offer users a portable specification for the
facility. Of course there is a risk that some users will misuse the feature,
but I don't think that's a very good argument for not making it available.
On the other hand indirect function calls introduced in xpath
2.1 give enough power to model dynamic flexibility, if required.
Indeed, and hopefully that will reduce the temptation to use dynamic
evaluation for solving problems in cases where higher-order functions are a
more appropriate solution. But there are many applications where reading
XPath expressions from data files or constructing then dynamically from
user-supplied input is a requirement, and currently such applications cannot
be written in a portable way.
For an example of such an application, consider the errata publication
system used for the XSLT and related specifications. The XML master file for
an erratum identifies the text to be changed or deleted by means of an XPath
expression embedded in the XML document, and the stylesheet uses this to
find the text and display it. This is a perfectly reasonable design, and
it's frankly embarrassing that the build system for the XSLT specification
should have to rely on vendor extensions to the language.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>