Re: [xsl] Re: First public working draft of XSLT 2.1

[ac <ac@xxxxxxxxxxxxx>]

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/