[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: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 15 Feb 2015 23:02:47 -0000

Thank you, Dr. Kay,

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

Then I think the phrase "and they may disable it unconditionally"
reflects the requirement (b) above.

Is my understanding correct?



--
Cheers,
Dimitre Novatchev



On Sun, Feb 15, 2015 at 1:02 PM, Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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