Bug 19671 - [XQ3.0] Backwards compatibility and the version declaration
[XQ3.0] Backwards compatibility and the version declaration
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0
Last Call drafts
PC All
: P2 normal
: ---
Assigned To: Jonathan Robie
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-23 16:54 UTC by Michael Kay
Modified: 2013-06-19 09:53 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kay 2012-10-23 16:54:04 UTC
We have achieved a very high level of backwards compatibility between XQuery 3.0 and 1.0, as evidenced by the empty content of Appendix J.1.

In fact there is one major backwards incompatibility which is not included in that list: an XQuery 3.0 processor is expected to reject a query that specifies a version declaration of "1.0".

If there were many incompatibilities, this would make sense. But there are not. If we believe that the list of incompatibilities is correct except for this omission, then it makes no sense to require a 3.0 processor to reject a 1.0 query, and I propose that we change the rule.
Comment 1 Andrew Eisenberg 2012-10-28 21:14:59 UTC
I'm not sure that I understand your concern. We say, "If an XQuery 3.0 processor processes a module labeled with a version of "1.0", it must either raise a static error [err:XQST0031], or attempt to process the module with an XQuery 1.0 processor."

An XQuery 3.0 processor can also be an XQuery 1.0 processor if it recognizes XQuery 1.0 syntax and provides XQuery 1.0 semantics.

An XQuery 3.0 processor might be given:

xquery version "1.0"; count(./products/product)

and return 12.

It might be given:

xquery version "1.0";
for $p in ./products/product
group by $cat := $p/category
return <products category="{$cat}" count="{count($p)}" />

and return XPST0003.

This allows an author to use some XQuery 3.0 processors to write XQuery 1.0 modules that will work with other XQuery 1.0 processors.
Comment 2 Michael Kay 2012-10-28 21:50:59 UTC
Under the rules as currently written, an XQuery 3.0 processor either has to incorporate an XQuery 1.0 processor (which means, for example, that it has to understand and enforce all the rules for module circularity that have been swept away in XQuery 3.0), or it has to reject a query labelled as XQuery 1.0. I don't believe that implementors of XQuery 3.0 processors will relish the prospect of implementing (or retaining an implementation of) restrictions that are no longer relevant in the 3.0 specification, but the alternative of rejecting valid XQuery 1.0 queries is equally unpleasant.

But at the very least we need to add an entry to the currently empty list of incompatibilities, to say that a (pure) XQuery 3.0 processor rejects all queries labelled as XQuery 1.0.
Comment 3 Josh Spiegel 2012-10-29 22:06:38 UTC
A slight downside I see is that if the policy is changed to "accept", it becomes a little awkward if the 3.0 processor encounters a 1.0 labeled module using updates.  Strictly speaking, I would expect it to raise an error as if updates do not exist until XQuery Update 3.0 goes REC. In the current spec, the bit that reads "... or attempt to process the module with an XQuery 1.0 processor. " handles this case cleanly.  

Switching to "accept" seems more tolerable if there very little chance that XQuery Update 3.0 will introduce a backwards incompatibility.  On this same note, can we be sure that XQuery 4.0 won't introduce a backwards incompatibility with 3.0?
Comment 4 Jim Melton 2012-10-30 10:55:43 UTC
At its F2F meeting on 2012-10-30, the WGs agreed to adopt a version-number policy that is outlined by the following bullet points:

XQuery processor that implements version "n.m"

* If given a query specifying version "n.m", then evaluate it using
"n.m" rules

* If given a query without a version specification, then evaluate
it using "n.m" rules

* If given a query specifying version "x.y":

- If able to process query strictly as version "x.y", then may do so

- If unable to process query as version "x.y", but "willing and able"
to evaluate query as version "n.m", then
  # may give warning
  # Evaluate using version "n.m" rules

- Otherwise, error


The Editor will wordsmith this policy properly.
Comment 5 Jonathan Robie 2012-10-30 12:45:04 UTC
> The Editor will wordsmith this policy properly.

Here's my first attempt.

[Definition: A version declaration can identify the applicable XQuery syntax and semantics for a module, as well as its encoding.] The version number "1.0" indicates a requirement that the module must be processed by an XQuery 1.0 processor; the version number "3.0" indicates a requirement that the module must be processed by an XQuery 3.0 processor. If the version declaration is not present or the version is not included in the declaration, an XQuery 3.0 processor assumes a version of "3.0".

If an XQuery 3.0 processor processes a module labeled with a version other than "3.0", it must do one of the following:

* Evaluate the query using the semantics of the XQuery version specified in the version declaration.

* Evaluate the query using the semantics of XQuery 3.0.
  Note: An implementation may issue a warning in this case. 

* Raise a static error [err:XQST0031].
Comment 6 Jonathan Robie 2012-10-30 14:04:09 UTC
(In reply to comment #5)
>  The version number 1.0" indicates a requirement 

s/requirement/intent

> * Evaluate the query using the semantics of the XQuery version specified in
> the version declaration.

s/Evaluate the query/process the module
s/semantics/specification
/s/version specified in/identified in/

> * Evaluate the query using the semantics of XQuery 3.0.
>   Note: An implementation may issue a warning in this case. 

s/semantics/specification/

> * Raise a static error [err:XQST0031].