Bug 19655 - Dependency conflict
Dependency conflict
Status: RESOLVED WONTFIX
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite
Working drafts
PC All
: P2 normal
: ---
Assigned To: O'Neil Delpratt
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-22 15:00 UTC by Ghislain Fourny
Modified: 2013-01-02 12:42 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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?