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

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

> 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@xxxxxxxxxxxx> 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
>
>



--
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.