self:: axis inside predicate throws XPST0005 #2445

rvdb · 2019-01-29T14:12:25Z

What is the problem

When used inside a predicate, the self:: axis throws error XPST0005 in some cirumstances, even though nothing is wrong with the expression. This happens with the most recent eXist releases 4.5.0 and 5.0.0-RC5 (and earlier releases).

What did you expect

I would expect the query to run without errors (confirmed with Saxon).

Describe how to reproduce or add a test

Behaviour is the same for in-memory and stored nodes, so these stand-alone test cases will illustrate the problem.

[1]

let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>
return 
    $node/el[self::el1]

This should return an empty result set. Instead following error is being thrown:

org.xmldb.api.base.XMLDBException: exerr:ERROR err:XPST0005 Self::{}el1 called on set of nodes which do not contain any nodes of this name. [at line 5, column 23, source: let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>
return $node/el[self::el1]] [at line 5, column 23]
  at org.exist.xmldb.RemoteXPathQueryService.compile(RemoteXPathQueryService.java:130)
  at org.exist.client.QueryDialog$QueryThread.run(QueryDialog.java:558)
Caused by: org.exist.xquery.XPathException: exerr:ERROR err:XPST0005 Self::{}el1 called on set of nodes which do not contain any nodes of this name. [at line 5, column 23, source: let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>
return $node/el[self::el1]] [at line 5, column 23]
  at org.exist.xmldb.RemoteXPathQueryService.throwXPathException(RemoteXPathQueryService.java:179)
  at org.exist.xmldb.RemoteXPathQueryService.compileAndCheck(RemoteXPathQueryService.java:155)
  at org.exist.xmldb.RemoteXPathQueryService.compile(RemoteXPathQueryService.java:128)
  ... 1 more
Caused by: org.exist.xquery.XPathException: exerr:ERROR err:XPST0005 Self::{}el1 called on set of nodes which do not contain any nodes of this name. [at line 5, column 23, source: let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>
return $node/el[self::el1]] [at line 5, column 23]
  at org.exist.xmldb.RemoteXPathQueryService.throwXPathException(RemoteXPathQueryService.java:179)
  at org.exist.xmldb.RemoteXPathQueryService.compileAndCheck(RemoteXPathQueryService.java:155)
  at org.exist.xmldb.RemoteXPathQueryService.compile(RemoteXPathQueryService.java:128)
  at org.exist.client.QueryDialog$QueryThread.run(QueryDialog.java:558)

Of course, this example is contrived, in order to present a simple test case. It seems, however, that the empty node set returned by the test condition in the predicate is significant. If the self:: axis does select a node (e.g. $node/el[self::el]), the query does run without error.

[2]

I've found another failing variant XQuery where the self:: axis occurs inside a predicate and doesn't select a node. Here, parentheses seem to be triggering the same error:

let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>
return $node/el[descendant::*/(self::el1)]

This should return the node:

<el>test <el1>test</el1> test <el2>test</el2></el>

Instead, above error XPST0005 is being thrown.

Here, the parentheses seem to be crucial. Compare with the same predicate without parentheses:

let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>
return $node/el[descendant::*/self::el1]

...which does return the correct result:

<el>test <el1>test</el1> test <el2>test</el2></el>

I've found a reference to this error message in the ML archives (https://sourceforge.net/p/exist/mailman/message/32496312/), and a bug fix in Github. So there's a chance this issue is related to #249.

Context information

Please always add the following information

eXist-db version + Git Revision hash:
- eXist-4.5.0 / e29b409
- eXist-5.0.0-RC5 / 4414b1a
Java version: oracle 1.8.0_191
Operating system: Windows 10
32 or 64 bit: 64 bit
How is eXist-db installed? JAR installer
Any custom changes in e.g. conf.xml: none

The text was updated successfully, but these errors were encountered:

duncdrum · 2019-06-13T12:14:53Z

@wolfgangmm as the author of #249 could you chime in here. I can reproduce these errors, but i am not sure what the optimal fix is here, should [1] really return an empty sequence?

line-o · 2020-12-05T13:28:56Z

Retested with e2bf08c
Putting ./ in front of the SELF-axis XPath-(sub-)expressions mitigates the problem.
Maybe, this can also help in tracking down the root-cause.

let $node := 
  <test>
    <el>test <el1>test</el1> test <el2>test</el2></el>
  </test>

return (
    $node/el[./self::el1],
    $node/el[./descendant::*/self::el1],
    $node/el[descendant::*/self::el1],
    $node/el[descendant::*/(./self::el1)]
)

line-o · 2020-12-05T15:26:05Z

Maybe, this can also help in tracking down the root-cause.

It confirms that the optimisation added in #249 is the culprit.

While [self::el1] is considered a simple query [./self::el1] is not and therefore is evaluated correctly.

line-o · 2020-12-05T15:32:18Z

@wolfgang @adamretter Maybe it would be enough to return an empty sequence instead of throwing an error in these two cases?

exist/exist-core/src/main/java/org/exist/xquery/LocationStep.java

Lines 273 to 281 in 34767fa

    
           if (parent.getSubExpressionCount() == 1 && !Type.subTypeOf(getTest().getType(), cStep.getTest().getType())) { 
        
               throw new XPathException(this, 
        
                       ErrorCodes.XPST0005, "Got nothing from self::" + getTest() + ", because parent node kind " + Type.getTypeName(cStep.getTest().getType())); 
        
           } 
        
           if (parent.getSubExpressionCount() == 1 && !(cStep.getTest().isWildcardTest() || getTest().isWildcardTest()) && !cStep.getTest().equals(getTest())) { 
        
               throw new XPathException(this, 
        
                       ErrorCodes.XPST0005, "Self::" + getTest() + " called on set of nodes which do not contain any nodes of this name."); 
        
           }

joewiz · 2020-12-05T16:39:48Z

A simplified test:

<foo><bar/></foo>/bar[self::baz]

Returns a static error:

Self::{}baz called on set of nodes which do not contain any nodes of this name.

The same query returns the empty sequence in BaseX and Saxon. Only eXist raises this error.

eXist correctly returns empty sequence for other axes:

<foo><bar/></foo>/bar[
    ancestor::baz | ancestor-or-self::baz | attribute::baz | 
    child::baz | descendant::baz | descendant-or-self::baz | 
    following::baz | following-sibling::baz | parent::baz | 
    preceding::baz | preceding-sibling::baz
]

Introducing | self::baz into the predicate triggers the error.

line-o · 2020-12-05T23:24:43Z

I have a fix in the making.

Fixes eXist-db#2445 By definition the following Xpaths must evaluate to an empty sequence - `<a/>[self::b]` - `<a/>/@b/c` - `<a/>/text()/b` Instead of throwing an Exception the staticReturnType of the current step and the contextInfo returnType are set to Type.EMPTY.

line-o · 2020-12-07T17:09:33Z

The question whether this is a bug or the expected behaviour is a general decision the existdb community has to answer: Do we provide the StaticTyping feature or not.

Even if we decide to adhere to provide the StaticTyping feature it is:

not fully implemented
needs to be clearly communicated to users

joewiz · 2020-12-07T19:01:50Z

As discussed during the Community Call, eXist doesn't implement the Static Typing optional feature (https://www.w3.org/TR/xquery-31/#id-static-typing-feature). Next actions:

Update documentation to note this: https://exist-db.org/exist/apps/doc/xquery#unsupported-features
Update exist-xqts-runner to set flag to disable static typing tracing: https://github.com/eXist-db/exist-xqts-runner/blob/master/src/main/scala/org/exist/xqts/runner/XQTSRunner.scala#L84-L97

Fixes eXist-db#2445 By definition the following Xpaths must evaluate to an empty sequence - `<a/>[self::b]` - `<a/>/@b/c` - `<a/>/text()/b` Instead of throwing an Exception the staticReturnType of the current step and the contextInfo returnType are set to Type.EMPTY.

refs eXist-db#2445 These tests aim to ensure that certain XPath expressions no longer raise error XPST0005 as exist-db does not implement the static typing feature and this feature is even dropped entirely with the next version of XQuery.

ghost added the triage issue needs to be investigated label Jan 29, 2019

duncdrum added the investigate issues being looked at label Jun 13, 2019

ghost removed the triage issue needs to be investigated label Jun 13, 2019

joewiz added the xquery issue is related to xquery implementation label Dec 5, 2020

joewiz added this to the eXist-5.2.1 milestone Dec 5, 2020

joewiz added bug issue confirmed as bug and removed investigate issues being looked at labels Dec 5, 2020

line-o mentioned this issue Dec 6, 2020

allow static type mismatches in XPath expressions #3653

Closed

line-o modified the milestones: eXist-5.2.1, eXist-6.0.0, eXist-5.3.1 Jun 28, 2021

adamretter modified the milestones: eXist-5.3.1, eXist-5.3.2 Dec 16, 2021

adamretter modified the milestones: eXist-5.3.2, eXist-6.0.2 Feb 14, 2022

adamretter modified the milestones: eXist-6.0.2, eXist-6.1.1 Jan 15, 2023

adamretter modified the milestones: eXist-6.1.1, eXist-7.0.1 Feb 4, 2023

line-o linked a pull request Mar 16, 2025 that will close this issue

No static typing #5673

Open

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

self:: axis inside predicate throws XPST0005 #2445

self:: axis inside predicate throws XPST0005 #2445

rvdb commented Jan 29, 2019

duncdrum commented Jun 13, 2019

Uh oh!

line-o commented Dec 5, 2020

Uh oh!

line-o commented Dec 5, 2020 •

edited

Loading

Uh oh!

line-o commented Dec 5, 2020

Uh oh!

joewiz commented Dec 5, 2020 •

edited

Loading

Uh oh!

line-o commented Dec 5, 2020

Uh oh!

line-o commented Dec 7, 2020

Uh oh!

joewiz commented Dec 7, 2020

Uh oh!

Uh oh!

self:: axis inside predicate throws XPST0005 #2445

self:: axis inside predicate throws XPST0005 #2445

Comments

rvdb commented Jan 29, 2019

What is the problem

What did you expect

Describe how to reproduce or add a test

[1]

[2]

Context information

duncdrum commented Jun 13, 2019

Uh oh!

line-o commented Dec 5, 2020

Uh oh!

line-o commented Dec 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

line-o commented Dec 5, 2020

Uh oh!

joewiz commented Dec 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

line-o commented Dec 5, 2020

Uh oh!

line-o commented Dec 7, 2020

Uh oh!

joewiz commented Dec 7, 2020

Uh oh!

line-o commented Dec 5, 2020 •

edited

Loading

joewiz commented Dec 5, 2020 •

edited

Loading