Possible optimizer bug when referencing collections from within predicates

[JensErat]

As described in the Stack Overflow question XPath: What does the «/» operator at the beginning of a rooted path expression exactly match?, it seems BaseX' behavior regarding predicates and collections is a little bit surprising.

Example Input

Two files in a folder forming a collection later:

• /foo/myDocs/1.xml: <root myAtt="one"/>
• /foo/myDocs/2.xml: <root myAtt="two"/>

The Issue

Running a query

collection('/tmp/myDocs')[/root/@myAtt = 'one']

resulting in

<root myAtt="one"/>
<root myAtt="two

to filter the documents still returns both <root/> nodes in BaseX, not in Saxon, which only returns the first document:

<root myAtt="one"/>

BaseX is optimizing this to

((db:open-pre("myDocs",0), ...))[((db:open-pre("myDocs",0), ...)/*:root/@*:myAtt = "one")]

and replaces the implicit root(.) call with the internal db-open-pre statement returning the collection. To me, this looks like an optimizer issue.

Using an explicit root call

Considering the / and root() semantics, I would expect this merely to have the meaning of

collection('/tmp/myDocs')[root(.)/root/@myAtt = 'one']

with the optimized query

((db:open-pre("myDocs",0), ...))[(root(.)/root/@myAtt = "one")]

returning

<root myAtt="one"/>

which would mean the documents contained in the collection will be tested one by one.

Enforcing a self-step

Enforcing an explicit self-step also resolves the issue:

collection('/tmp/myDocs')/self::node()[/root/@myAtt = 'one']

returning the expected

<root myAtt="one"/>

[ChristianGruen]

Thanks for the detailed explanation; I agree.

[ChristianGruen]

A command-script to reproduce:

<commands>
  <create-db name='db'/>
  <add path='a.xml'><a/></add>
  <add path='b.xml'><b/></add>
  <xquery>.[/a]</xquery>
  <drop-db name='db'/>
</commands>