19671 2012-10-23 16:54:04 +0000 [XQ3.0] Backwards compatibility and the version declaration 2013-06-19 09:53:51 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.0 Last Call drafts PC All CLOSED FIXED P2 normal --- 1 mike jonathan.robie andrew.eisenberg jim.melton josh.spiegel public-qt-comments oldest_to_newest 76967 0 mike 2012-10-23 16:54:04 +0000 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. 77221 1 andrew.eisenberg 2012-10-28 21:14:59 +0000 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. 77224 2 mike 2012-10-28 21:50:59 +0000 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. 77336 3 josh.spiegel 2012-10-29 22:06:38 +0000 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? 77399 4 jim.melton 2012-10-30 10:55:43 +0000 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. 77409 5 jonathan.robie 2012-10-30 12:45:04 +0000 > 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]. 77421 6 jonathan.robie 2012-10-30 14:04:09 +0000 (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].