RE: Required cardinality checks

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:  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?