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(_at_)saxonica(_dot_)com
+44 (0) 118 946 5893
On 15 Feb 2015, at 17:52, Dimitre Novatchev dnovatchev(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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-feature)
, 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
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--