[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT 3.0: Question about: Disabling dynamic evaluation unconditionally


Subject: Re: [xsl] XSLT 3.0: Question about: Disabling dynamic evaluation unconditionally
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 15 Feb 2015 21:02:24 -0000

As I understand it, there are two kinds of anxiety about xsl:evaluate that led
to these provisions being included in the spec: anxieties that dynamic XPath
evaluate could cause a security risk (through executing untrusted code), and
anxiety about the necessity to include a complete XPath parser in the
execution environment, especially in environments with limited resources such
as mobile or embedded devices. I think the working group therefore felt that
(a) there should always be a way for users (or system managers) to disable the
feature, and (b) on some environments, such as mobile devices, the feature
might not be available at all.

Michael Kay
Saxonica
mike@xxxxxxxxxxxx
+44 (0) 118 946 5893




On 15 Feb 2015, at 17:52, Dimitre Novatchev dnovatchev@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi,
> At the end of Section "10.4.4 xsl:evaluate as an optional feature" of
> the 2nd Last Call of the W3C XSLT 3.0 specification
>
(http://www.w3.org/TR/2014/WD-xslt-30-20141002/#evaluation-as-optional-featur
e)
> , the last paragraph says:
>
> "Processors that implement xsl:evaluate should provide mechanisms
> allowing calls on xsl:evaluate to be disabled. Implementations may
> disable the feature by default, and they may disable it
> unconditionally."
>
> My question is:
> What is meant here by "they may disable it unconditionally" ?
>
> Is this something the XSLT processor decides by itself if a certain
> kind of event occurs, and does disabling the feature "unconditionally"
> mean that after the disablement, the feature can never be enabled
> again?
>
> --
> Cheers,
> Dimitre Novatchev


Current Thread
Keywords