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?
I understand that there will be use cases almost for any feature, whatever.
But Occam's razor principle suggests to restrict oneself, otherwise you will
never know what do you really need, and what you don't.
I remember very well a question that survives many years:
"why does my xpath not select elements from a, with names stored in $b:
a/$b?"
People will find a new answer to it.
--
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>
--~--