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 19655 - Dependency conflict
Summary: Dependency conflict
Status: RESOLVED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: O'Neil Delpratt
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-22 15:00 UTC by Ghislain Fourny
Modified: 2013-01-02 12:42 UTC (History)
2 users (show)

See Also:


Attachments

Description Ghislain Fourny 2012-10-22 15:00:58 UTC
In the test CastAs-UnionType-1, it is both specified XQ30+ as a dependency (potentially allowing future versions), and a frozen version of "3.0" in the code. Could it be that one needs to either (i) remove the + in the dependency or (ii) remove the frozen version?
Comment 1 Michael Kay 2012-10-22 15:12:34 UTC
I think we don't really need to address this problem until we know whether XQuery 3.1 (for example) will accept queries labelled as "xquery version '3.0'". My hope is that it will.

However, our general practice has been to omit the query version declaration from test queries, partly because in many cases this enables them also to act as XPath expressions.
Comment 2 Sorin Nasoi 2012-10-23 17:51:36 UTC
(In reply to comment #1)
> I think we don't really need to address this problem until we know whether
> XQuery 3.1 (for example) will accept queries labelled as "xquery version
> '3.0'". My hope is that it will.
> 
> However, our general practice has been to omit the query version declaration
> from test queries, partly because in many cases this enables them also to
> act as XPath expressions.
I see your point but the better solution would be, IMHO, to omit the "dependency" to "XQ30" or "XQ30+" because if we omit the query version declaration from the test this means altering the test which we should not do, right?
Comment 3 Michael Kay 2012-10-23 20:04:05 UTC
It's universal practice throughout the test suite to label tests as say XQnn if they are known to require an exact version and XQnn+ if there is a reasonable expectation that they will run on future versions also.

At present the ONLY backwards incompatibility between XQuery 1.0 and 3.0 is that XQuery 3.0 will not run a query that specifies 1.0 in its version declaration. I've raised a bug against that because it seems absurd that the only backwards incompatibility should be such an unnecessary one. However, if it remains WG policy for version numbers to work this way, then users who want their queries to be forwards compatible will be well advised not to include a version number in the prolog, and the same goes for tests in the test suite.

Meanwhile, we have to take a punt on whether our queries are likely to run under 3.1 or not. There is no way of knowing, so we have to guess, and I think it's better to make the same guess everywhere, which is that they will run under future versions. It's easier to change it across the board if we have made the same policy decision across the board.
Comment 4 O'Neil Delpratt 2013-01-02 12:42:03 UTC
(In reply to comment #1)
> However, our general practice has been to omit the query version declaration
> from test queries, partly because in many cases this enables them also to
> act as XPath expressions.

There are approx. 50 tests that include the query version. I am inclined to leave the queries as they are and leave the dependencies which specify XQ30+, therefore rejecting this bug. Is that Ok?