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 26788 - [XPath30] XQuery-only errors in XPath 3.0 specification, like XQST0134
Summary: [XPath30] XQuery-only errors in XPath 3.0 specification, like XQST0134
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-13 16:19 UTC by Abel Braaksma
Modified: 2014-10-14 08:46 UTC (History)
2 users (show)

See Also:


Attachments

Description Abel Braaksma 2014-09-13 16:19:56 UTC
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.
Comment 1 Jonathan Robie 2014-09-16 14:55:02 UTC
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.
Comment 2 Jonathan Robie 2014-09-30 21:29:37 UTC
(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.
Comment 3 Jonathan Robie 2014-09-30 21:50:53 UTC
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>
Comment 4 Michael Dyck 2014-09-30 22:52:08 UTC
(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.)
Comment 5 Jonathan Robie 2014-10-01 00:31:54 UTC
(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>
Comment 6 Michael Dyck 2014-10-01 02:26:51 UTC
(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.
Comment 7 Jonathan Robie 2014-10-01 02:52:57 UTC
(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?
Comment 8 Jonathan Robie 2014-10-02 00:47:00 UTC
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>
Comment 9 Jonathan Robie 2014-10-02 01:05:23 UTC
Fixed in 3.1, but not in 3.0
Comment 10 Abel Braaksma 2014-10-02 02:09:49 UTC
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?
Comment 11 Michael Dyck 2014-10-02 03:42:40 UTC
(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.
Comment 12 Jonathan Robie 2014-10-02 11:45:47 UTC
(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.
Comment 13 Michael Kay 2014-10-02 14:37:29 UTC
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.
Comment 14 Jonathan Robie 2014-10-02 14:39:36 UTC
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.
Comment 15 Michael Kay 2014-10-14 08:46:58 UTC
See also bug #12599