it seems reasonable to offer users a portable specification for the
facility.
In case issue 13 is decided in favor of this feature being optional,
then exactly the opposite effect of portability will be achieved.
I see the convenience of this feature, but if included it must not be optional.
Cheers,
Dimitre
On Sat, May 15, 2010 at 12:51 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
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
excessive overhead.
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.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
--~------------------------------------------------------------------
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>
--~--
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
I enjoy the massacre of ads. This sentence will slaughter ads without
a messy bloodbath.
--~------------------------------------------------------------------
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>
--~--