Hi Vladimir,
I understand your concerns but feel that you may be forgetting many very
useful use cases and, if I understand well what you mean by "the worst
effect will be from developers who will widely practice the "easiest"
way to achieve desired effect with dynamic xpath", I would think that
any function, instruction, or feature can be misused and typically is,
sometimes. That does not mean that we should remove them all, does it?
If you built smart XML layouts, for example, with embedded rules, to
query/fetch content, for example, would you define your own rule
language and create your custom rule language interpreter, or would you
not do that and rather hardwire all your queries in the applications,
forcing users to modify the applications if they need to
change/add/remove queries and/or layouts, or would you prefer using
xpath and evaluate(), or do you have some other way of handling this?
Compilation and interpreters are not mutually exclusive and interpreters
have proven their usefulness. Of course, if you compile to native code,
without external run-time support, you probably need to handle run-time
internally, and the less features to support, the less code you may have
to write/compile/deploy, but again, removing everything may be even better.
I am sorry to disagree, but evaluate() seems very valuable. We have
more compelling use cases for it and I am happy that it will finally be
part of the standard.
OTOH, I agree that higher-order functions are indeed very useful too.
Regards,
ac
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.
But probably the worst effect will be from developers who will widely
practice the "easiest" way to achieve desired effect with dynamic xpath.
On the other hand indirect function calls introduced in xpath 2.1 give
enough power to model dynamic flexibility, if required.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com/
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--