Subject: RE: [xsl] Required cardinality checks|
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Wed, 30 Sep 2009 22:47:38 +0100
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@xxxxxxxxx] > Sent: 30 September 2009 22:36 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > 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?