Re: [XSLT 2.0] Basic XSLT processor {qt-2003Dec0165-01}

David Carlisle pointed out in comment

http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0165.html

that it would be useful to be able to write conditional sections in a
stylesheet for schema-aware and non-schema-aware XSLT processors, and
that this would require some static errors to be changed to dynamic
errors. The Working Group agrees that this is a requirement, but is
reluctant to reduce the ability of a processor to report errors at
compile time.

Leaning in the opposite direction, I pointed out in an internal comment

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jan/0012.html

that it would be useful to raise a static error rather than a dynamic
error when an XPath expression contains a call to a non-existent
stylesheet function. Currently this is a dynamic error, to allow
stylesheets to be written that work on different XSLT processors
providing different libraries of extension functions. As a result, it
can happen that incorrect function calls are not reported as an error
until the first time the stylesheet is executed using data that invokes
the function call, which can be problematic when there are many template
rules that process rarely-encountered elements.

To address both these comments, the WG proposes to introduce variants of
the xsl:if and xsl:choose instructions that make a compile-time choice.
Static errors in a branch that is "not chosen" will not be reported.

As editor I have been actioned to produce a detailed proposal, which I
will do on an internal list. The thinking is:

(a) provide a new attribute on xsl:if and xsl:when as an alternative to
"test", for example, "configuration". For example, <xsl:when
configuration="system-property('xsl:schema-aware')='yes'">

(b) define a subset of the XPath language that can be evaluated at
compile time. This will include the ability to test on
system-property(), function-available(), and element-available(). There
have been several suggestions for how to do this:

   (i) constructively, by listing the constructs that can be used in
such expressions
   (ii) subtractively, by listing the constructs that cannot be used
   (iii) implicitly, by allowing the full XPath language but specifying
that the dynamic context is effectively empty, causing all expressions
that rely on the dynamic context to fail. Our initial leaning is towards
(i) but we will explore the other options.

To meet the user requirement suggested by David, it will also be
necessary for a non-schema-aware processor to ignore (rather than
reject) xsl:import-schema declarations.

We are thinking of making a reference to an undeclared function into a
static error, unless it is contained in an ignored section. This would
be a backwards incompatibility.

For the time being we are leaving the comment open. David, if you have
any comments on the direction we are taking, please let us know.

Michael Kay

Received on Sunday, 25 January 2004 16:47:40 UTC