These rules have led to a great deal of debate, and there is certainly room
for different interpretations. Note also that there are a number of
published errata in this area. However, the sentence
If a processor evaluates an operand E (wholly or in part), then it is
required to establish that the actual value of the operand E does not
violate any constraints on its cardinality.
was carefully written: the implication is that if the processor does not
evaluate E, then it is NOT required to check the cardinality of E.
(This for some reason reminds me of a sentence in the English Missal: "If
the Alleluia is not sung then it may be omitted".)
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
-----Original Message-----
From: Pavel Minaev [mailto:int19h(_at_)gmail(_dot_)com]
Sent: 30 September 2009 22:36
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] Required cardinality checks
XPath 2.0 spec has the following bit in "2.3.4. Errors and
Optimization" section, after asserting that "optimizing away"
errors is generally permitted:
"There is an exception to this rule: If a processor evaluates
an operand E (wholly or in part), then it is required to
establish that the actual value of the operand E does not
violate any constraints on its cardinality. For example, the
expression $e eq 0 results in a type error if the value of $e
contains two or more items. A processor is not allowed to
decide, after evaluating the first item in the value of $e
and finding it equal to zero, that the only possible outcomes
are the value true or a type error caused by the cardinality
violation. It must establish that the value of $e contains no
more than one item."
On the other hand, "3.1.5 Function calls" describes the call
as follows:
"A function call is evaluated as follows:
1. Argument expressions are evaluated, producing argument
values. The order of argument evaluation is
implementation-dependent and a function need not evaluate an
argument if the function can evaluate its body without
evaluating that argument.
2. Each argument value is converted by applying the function
conversion rules listed below.
..."
And any type errors because of mismatch of expected and
actual types of function arguments are described further in
section detailing the function conversion rules referenced in
step 2. Since step 2 might not even be reached for any given
argument if its value is unused, does this imply that a
conformant implementation is at liberty to elide any any type
checking (including cardinality checks) for specific
arguments? For example:
<xsl:function name="my:foo">
<xsl:param name="x"/>
<xsl:param name="ys" as="item()+"/>
<xsl:if test="$x ne 0">
<xsl:value-of select="$ys[$x]"/>
</xsl:if>
</xsl:function>
...
<xsl:value-of select="my:foo(0, ())"/>
This passes an empty sequence to a function argument with
cardinality of 1-or-more, but the argument is not actually
evaluated. Should this require a dynamic error to be raised
according to 2.3.4, or is the implementation allowed to skip
the check, and return an empty sequence, by rules of 3.1.5?
Also, what about <xsl:call-template> in a similar context?
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--