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 29526 - [XQ31] Incompatible change to ExtensionExpr
Summary: [XQ31] Incompatible change to ExtensionExpr
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-09 23:27 UTC by Michael Kay
Modified: 2016-03-18 15:28 UTC (History)
3 users (show)

See Also:

Attachments

Description Michael Kay 2016-03-09 23:27:22 UTC 
In XQuery 1.0 and 3.0, It was defined that the construct

(# pragma #) {}

raised a static error if the pragma was not recognized by the query processor.

In XQuery 3.1 this now returns an empty sequence when the pragma is not recognized.

Although we don't normally treat the abolition of a static error as an incompatibility, I'm worried that we have removed a useful capability here. This construct could be used to make it clear that a query relied on a vendor extension and that no fallback was available. It's a construct that was valid and had a well-defined meaning, and we have changed that meaning. Can we please think again?
Comment 1 Andrew Coleman 2016-03-18 15:07:47 UTC 
At the meeting on 2016-03-22, the WG agreed to revert this to its previous behaviour.  The grammar will also be reverted so that ExtensionExpr does use EnclosedExpr.
Comment 2 Michael Dyck 2016-03-18 15:23:52 UTC 
(... so that it does *not* use EnclosedExpr, actually.)
Comment 3 Josh Spiegel 2016-03-18 15:28:33 UTC 
Apologies, looks like I got it wrong in the minutes:   

ACTION A-636-09:  Michael Dyck to revert the grammar so that ExtensionExpr does use EnclosedExpr (see bug 29526).

Should say *does not*