This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2708 - Errors and Optimization and Cardinality checks
Summary: Errors and Optimization and Cardinality checks
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-11 21:55 UTC by Michael Kay
Modified: 2006-02-15 21:59 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-01-11 21:55:03 UTC
Section 2.3.4 says:

"Another consequence of these rules is that where none of the items in a
sequence contributes to the result of an expression, the processor is not
obliged to evaluate any part of the sequence. Again, however, the processor
cannot dispense with a required cardinality check: if an empty sequence is not
permitted in the relevant context, then the processor must ensure that the
operand is not an empty sequence."

It's not clear quite how much checking this requires.

Consider

(1,2,3) = (1,2,exactly-one(//title))

//title is not allowed to return an empty sequence. Does this mean we are
required to evaluate it and check it? I think we would agree that it does not.
In other words, the requirement to do cardinality checking does not cascade.

Now consider

max((), resolve-uri($collation, 'http://base/'))

Does the quoted paragraph mean that I am required to determine that the
collation is not (), even though the result of the max() function is clearly (),
regardless of the actual collation? It seems to me that the wording of the above
paragraph says that this is indeed required. If that's the case, it seems wrong:
it's a quite unnecessary constraint on the way the processor operates. Whether
the decision is made statically or dynamically, we should always have the
freedom to avoid evaluating an expression if its value is not needed.

Perhaps we could use a form of words such as: if an expression is evaluated
(wholly or in part), then it must be evaluated sufficiently to ensure that any
cardinality constraints on the value of the expression are satisfied.

Michael Kay
Comment 1 Don Chamberlin 2006-02-15 21:59:26 UTC
Mike,
The Query and XSLT working groups considered your comment during their joint 
meeting on 01 Feb 2006, and agreed to make editorial changes to Section 2.3.4 
(Errors and Optimization) of the XPath and XQuery specifications, clarifying 
that cardinality checking is required only for expressions that are evaluated, 
wholly or in part. Since you were present at the discussion, I have marked this 
issue as Closed.
Regards,
Don Chamberlin (for the joint working groups)