26788 2014-09-13 16:19:56 +0000 [XPath30] XQuery-only errors in XPath 3.0 specification, like XQST0134 2014-10-14 08:46:58 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.0 Recommendation PC Windows NT RESOLVED FIXED P2 normal --- 1 abel.braaksma jonathan.robie jmdyck mike public-qt-comments oldest_to_newest 111467 0 abel.braaksma 2014-09-13 16:19:56 +0000 Some errors seem to have gotten their way into the XPath 3.0 Recommendation (also the internal XPath 3.1 Draft) that are by name and intend XQuery-specific. err:XQST0134: XQuery 3.0 does not support the namespace axis. This error serves an XQuery-specific case. I think that both the error condition and the error code should be removed. If not, then it makes sense to rename the error code to XPST0134, in line with the naming conventions of XPath errors. Furthermore, the way it is written currently under 3.3.5, it appears that XPath 3.0 normatively prohibits the namespace axis, as the text says "if the NodeTest in an axis step is a NamespaceNodeTest then... error", but in the Note following the text, it makes this XQuery-specific. I think the following should be valid XPath: @namespace-node() Other cases, merely editorial, using the wrong naming conventions: err:XQST0039: "It is a static error for an inline function expression to have more than one parameter with the same name." Should be renamed XPST0039. err:XQST0046: "An implementation MAY raise a static error if the value of a BracedURILiteral is of nonzero length and is neither an absolute URI nor a relative URI." Should be renamed XPST0046. err:XQST0052: "The type must be the name of a type defined in the in-scope schema types, and the {variety} of the type must be simple." Should be renamed XPST0052. err:XQST0070: "A static error is raised if one of the predefined prefixes xml or xmlns appears in a namespace declaration or a default namespace declaration[...]" Should be renamed XPST0070. Note: in the current internal XPath 3.1 draft, err:XQDY0136, err:XQDY0137 have been introduced that ought to be errXPDY0136 and err:XPDY0137 respectively. 111590 1 jonathan.robie 2014-09-16 14:55:02 +0000 Nice catch. I can make sure that this does not appear in XPath 3.1: * err:XQST0134: XQuery 3.0 does not support the namespace axis. I don't think we can change the names of error conditions that have appeared in a Recommendation now. We should discuss how to handle 3.0 errata in a telcon. 112498 2 jonathan.robie 2014-09-30 21:29:37 +0000 (In reply to Jonathan Robie from comment #1) > Nice catch. > > I can make sure that this does not appear in XPath 3.1: > > * err:XQST0134: XQuery 3.0 does not support the namespace axis. > > I don't think we can change the names of error conditions that have appeared > in a Recommendation now. We should discuss how to handle 3.0 errata in a > telcon. In making this change, I realized that this occurs in the context of the abbreviated syntax, where the default axis is child. The text occurs here: http://www.w3.org/TR/xpath-30/#abbrev Namespace nodes can be found only on the namespace axis, never on the child axis or the attribute axis, so what is the correct behavior for XPath in this case, in a host language that supports the namespace axis? Saxon XSLT treats this as a warning, saying that the child axis will never return any namespace nodes. 112499 3 jonathan.robie 2014-09-30 21:50:53 +0000 Here is what I did for the XPath 3.1 draft: <quote> If the axis name is omitted from an axis step, the default axis is child, with two exceptions: if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; in an implementation that does not support the namespace axis, an error is raised [err:XQST0134]. Note: In an implementation that does not support the namespace axis, an attempt to access it always raises an error. Thus, an XQuery implementation will always raise an error in this case, since XQuery does not support the namespace axis. The namespace axis is deprecated as of XPath 2.0, but required in some languages that use XPath, including XSLT. </quote> <quote> err:XQST0134 The namespace axis is not supported. </quote> 112504 4 jmdyck 2014-09-30 22:52:08 +0000 (In reply to Jonathan Robie from comment #3) > > <quote> > If the axis name is omitted from an axis step, the default axis is child, > with two exceptions: if [...] then the default axis is attribute; in an > implementation that does not support the namespace axis, an error is raised > [err:XQST0134]. > </quote> No, if the second exception omits the syntactic constraint on the NodeTest, you're saying that, with an implementation that doesn't support 'namespace', you can only omit the axis name when it's 'attribute'. I think the text should be something like: <quote> If the axis name is omitted from an axis step, the default axis is 'child', with two exceptions: if [...] then the default axis is 'attribute'; if the NodeTest in an axis step is a NamespaceNodeTest then <xquery> a static error is raised [err:XQST0134], because XQuery does not support the namespace axis. </xquery> <xpath> in an implementation that supports the namespace axis, the default axis is 'namespace'; in an implementation that does not support the namespace axis, a static error is raised [err:XQST0134]. </xpath> </quote> (This might be more comprehensible if the two exceptions were formatted as bullet points. You could also start the bullets after "axis step", and add a third bullet: "Otherwise, the default axis is 'child'".) (In any case, I think you could omit the Note that follows.) 112509 5 jonathan.robie 2014-10-01 00:31:54 +0000 (In reply to Michael Dyck from comment #4) > I think the text should be something like: > > <quote> > If the axis name is omitted from an axis step, the default axis is 'child', > with two exceptions: if [...] then the default axis is 'attribute'; > if the NodeTest in an axis step is a NamespaceNodeTest then > <xquery> > a static error is raised [err:XQST0134], > because XQuery does not support the namespace axis. > </xquery> > > <xpath> > in an implementation that supports the namespace axis, the default axis is > 'namespace'; in an implementation that does not support the namespace > axis, > a static error is raised [err:XQST0134]. > </xpath> > </quote> I do not think that is the intended meaning of the text - neither XPath 1.0 nor XPath 2.0 ever default to the namespace axis in abbreviated syntax. But my text was also wrong, misuse of conditional markup ... here's a second try: <quote text="XPath 3.1"> If the axis name is omitted from an axis step, the default axis is child, with two exceptions: if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; if the NodeTest in an axis step is a NamespaceNodeTest in an implementation that does not support the namespace axis, an error is raised [err:XQST0134]. Note: The namespace axis is deprecated as of XPath 2.0, but required in some languages that use XPath, including XSLT. </quote> <quote text="XQuery 3.1"> If the axis name is omitted from an axis step, the default axis is child, with two exceptions: if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; if the NodeTest in an axis step is a NamespaceNodeTest then a static error is raised [err:XQST0134]. Note: The namespace axis is deprecated as of XPath 2.0, but required in some languages that use XPath, including XSLT. </quote> 112513 6 jmdyck 2014-10-01 02:26:51 +0000 (In reply to Jonathan Robie from comment #5) > > I do not think that is the intended meaning of the text - neither XPath 1.0 > nor XPath 2.0 ever default to the namespace axis in abbreviated syntax. Of course not: they don't have a syntactic context in which one would even contemplate defaulting to the namespace axis. That is, they don't have NamespaceNodeTest. That was introduced in XPath/XQuery 3.0 (or technically, XPath 2.1 / XQuery 1.1). And back then, the decision was that with a NamespaceNodeTest, the axis does indeed default to the namespace axis (which thus causes an error in impls of XPath that don't support the namespace axis, and in all impls of XQuery). See Bug 9298, comment #2. I'm pretty sure that decision wasn't subsequently overturned. 112515 7 jonathan.robie 2014-10-01 02:52:57 +0000 (In reply to Michael Dyck from comment #6) > And back then, the decision was that with a > NamespaceNodeTest, the axis does indeed default to the namespace axis (which > thus causes an error in impls of XPath that don't support the namespace > axis, and in all impls of XQuery). See Bug 9298, comment #2. > > I'm pretty sure that decision wasn't subsequently overturned. Hmmm, interesting. I tried this with Saxon EE 9.5.1.2: <xsl:template match="/top/namespace-node()"> <a>Hi, mom!</a> </xsl:template> and got the following error: "The child axis will never select any namespace nodes." But 9298#2 is quite clear. Does anyone else believe it was ever overturned? 112545 8 jonathan.robie 2014-10-02 00:47:00 +0000 Here's the final text for the LCWD: <xquery> If the axis name is omitted from an axis step, the default axis is child, with two exceptions: (1) if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; (2) if the NodeTest in an axis step is a NamespaceNodeTest then a static error is raised [err:XQST0134]. Note: The namespace axis is deprecated as of XPath 2.0, but required in some languages that use XPath, including XSLT. </xquery> <errors> err:XQST0134 The namespace axis is not supported. </errors> <xpath> If the axis name is omitted from an axis step, the default axis is child, with two exceptions: (1) if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; (2) if the NodeTest in an axis step is a NamespaceNodeTest then the default axis is namespace - in an implementation that does not support the namespace axis, an error is raised [err:XQST0134]. Note: The namespace axis is deprecated as of XPath 2.0, but required in some languages that use XPath, including XSLT. </xpath> 112547 9 jonathan.robie 2014-10-02 01:05:23 +0000 Fixed in 3.1, but not in 3.0 112549 10 abel.braaksma 2014-10-02 02:09:49 +0000 Are you sure it is fixed in 3.1 (the part on the error codes, I mean)? Because the LCWD of XPath 3.1 currently present at https://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xpath-31.html (member only) still mentions the XQuery-only error-codes: err:XQST0039, should be err:XPST0039 err:XQST0046, should be err:XPST0046 err:XQST0052, should be err:XPST0052 err:XQST0070, should be err:XPST0070 err:XQST0134, should be err:XPST0134 err:XQDY0137, should be err:XPST0137 or am I speaking too soon and was the change not published yet? Or, in response to: > I don't think we can change the names of error conditions that have > appeared in a Recommendation now. We should discuss how to handle 3.0 > errata in a telcon. Did you mean by that that you cannot change them in subsequent versions of the spec either? Because I was under the impression that error codes were changed between versions (think of the XSLT errors for XSLT 2.0 functions that moved to XPath 3.0 and the errors were renumbered). And if you have: a) mention them in an errata for 3.0 b) change them in subsequent versions then wouldn't that suffice? 112552 11 jmdyck 2014-10-02 03:42:40 +0000 (In reply to Jonathan Robie from comment #8) > Here's the final text for the LCWD: > > <xquery> > [...] > > Note: > > The namespace axis is deprecated as of XPath 2.0, but required in some > languages that use XPath, including XSLT. > </xquery> For the *XQuery* spec, a note here that only talks about XPath seems somewhat beside the point. Other than that, I think the text looks okay. 112569 12 jonathan.robie 2014-10-02 11:45:47 +0000 (In reply to Abel Braaksma from comment #10) > Are you sure it is fixed in 3.1 (the part on the error codes, I mean)? > Because the LCWD of XPath 3.1 currently present at > https://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xpath-31. > html (member only) still mentions the XQuery-only error-codes: > > err:XQST0039, should be err:XPST0039 > err:XQST0046, should be err:XPST0046 > err:XQST0052, should be err:XPST0052 > err:XQST0070, should be err:XPST0070 > err:XQST0134, should be err:XPST0134 > err:XQDY0137, should be err:XPST0137 We have a 3.0 Recommendation that uses those error codes, so we can't really change them now. Imagine a world in which moving from 3.0 to 3.1 changes the error codes that you get for the same error conditions ... especially if you have written code that depends on those codes. I did mention this in the Working Group telcon, and the Working Group affirmed that we should not change these codes now. One person made the very valid observation that we would have been better off with codes that do not identify the specification, since error conditions are shared across specifications and what is used by a given specification can change over time. 112588 13 mike 2014-10-02 14:37:29 +0000 One reason we felt able to change codes when moving things like format-date from XSLT 2.0 to XPath 3.0 is that XSLT 2.0 had made error codes very "low key", emphasizing that (a) conformant processors were not expected to generate the error codes, and (b) there was no interface in the spec that allowed applications access to them. These error codes are used to label error conditions in this specification... They are provided primarily for ease of reference. Implementations may use these codes when signaling errors, but they are not required to do so. That changes with 3.0 and try/catch. 112589 14 jonathan.robie 2014-10-02 14:39:36 +0000 I believe I have followed the WG's instructions on how to resolve this. I will close it again, feel free to reopen if you believe further discussion is needed. 113070 15 mike 2014-10-14 08:46:58 +0000 See also bug #12599