Predicates, sequences of numbers: Feedback

[ChristianGruen]

Predicates, sequences of numbers: Feedback

[michaelhkay]

This comes under the general rule that once you have read enough data to know that there is only one possible non-error result, you are not required to read extra data solely for the purpose of deciding whether there is an error. So reporting the error in this case is already optional.

This isn't quite the same as the 'OK'[ <a/>, 1, 'x' ] case, which isn't an error. The case 'OK'[ 1, <a/>, 'x' ] is an error, it's just one that you don't necessarily have to report.

We could, if we wanted, say that if the predicate value starts with a number, all non-numeric items in the value are ignored. But I don't think we should.

In the most common case for numeric predicates, the value of the predicate is going to be the same for every item in the input sequence, and in that situation you probably want to evaluate the predicate once in advance to determine all the positions that you want to select, rather than evaluating it once for every input item. So detecting the error doesn't cost you any extra. That's different from a boolean predicate such as p[child::*] where the predicate value usually depends on the context item.

[ChristianGruen]

This isn't quite the same as the 'OK'[<a/>, 1, 'x'] case, which isn't an error. The case 'OK'[1, <a/>, 'x'] is an error, it's just one that you don't necessarily have to report.

@michaelhkay Following this reasoning, wouldn’t it be be legal as well to raise no error for 'OK'['a', 'b'], as the first comparison is successful?

[ChristianGruen]

Could we allow implementations to return true for 'OK'[ 'a', 'b' ] – or is this already allowed?

[ChristianGruen]

…and would this also apply to EBV computations, i.e., would it be legal not to report the error for boolean(('a', 'b', 'c')) as boolean('a') is true ?

[michaelhkay]

If $seq starts with a number, E[$seq] and E[position() = $seq] will become equivalent:

I don't like that idea because it implies that if $seq contains nodes or untypedAtomic values after the first item, they are converted to numbers under the rules of general comparisons.

'OK'['a', 'b']

In general, Errors and Optimizations says you don't need to evaluate 'b' because its value doesn't affect the final result. the only caveat is whether it comes under the exception:

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.

It's not clear whether the EBV rule that computing the EBV of ('a', 'b') raises FORG0006 consitutes a "constraint on the cardinality" of the predicate expression. I don't think it does. But even if the spec allows 'b' to be ignored, I think raising the error here is the "right thing to do".

[ChristianGruen]

Thanks for the explanation.

I think raising the error here is the "right thing to do".

To achieve consistent behavior, we could turn it around and allow implementations to raise an error if the first item of a sequence is a node, but the second is not. Otherwise, we should possibly explain what (other than historical reasons) makes the following expressions behave differently:

$value[<a/>, 'x']
$value['x', <a/>]

[ndw]

At the very least, we need to clarify the spec.

[ChristianGruen]

These are the current rules for fn:boolean:

1. If $input is the empty sequence, fn:boolean returns false.
2. If $input is a sequence whose first item is a node, fn:boolean returns true.
3. If $input is a singleton value of type xs:boolean or a derived from xs:boolean, fn:boolean returns $input.
4. If $input is a singleton value of type xs:untypedAtomic, xs:string, xs:anyURI, or a type derived from xs:string or xs:anyURI, fn:boolean returns false if the operand value has zero length; otherwise it returns true.
5. If $input is a singleton value of any numeric type or a type derived from a numeric type, fn:boolean returns false if the operand value is NaN or is numerically equal to zero; otherwise it returns true.
6. In all other cases, fn:boolean raises a type error [err:FORG0006].

Maybe it’s sufficient to change rule 2:

2. If $input is a sequence of nodes, fn:boolean returns true.

The following query would then raise an error…

$value[<a/>, 'x']

Due to the rules Errors and Optimizations rules, an implementation would still be allowed to not raise the error (so the behavior would be backward-compatible), although I can imagine it would be… the right thing to do.

[michaelhkay]

It doesn't feel right to me to take something that is currently permitted and well-defined by the spec and turn it into an error, with no justification other than "tidying things up". The consequence of this proposed change is that:

(a) implementations may ignore it and continue as they are, but exploiting a loophole in the spec and not behaving as users reading the spec might expect.
(b) implementations may read the entire sequence to see if it contains any non-nodes; there usually won't be any, so the query will deliver the same result but be slower
(c) a small number of applications may actually be exploiting the rules as currently written, and may break as a result of the change.

None of these consequences seems desirable. What are we trying to achieve?

[ChristianGruen]

My justification would have been to make the EBV rules more consistent for different input types, and to (ideally) not have it rely on implementation-specific optimizations. We have three kinds of results that sometimes seem arbitrary (false, true, error).

But I understand that the implications would generally be too far-reaching. Thanks for the explanations; I’m closing the issue.