in xpath the predicate [bar='test'] would mean a child element that has one or more descendent text nodes that evaluates to 'test'.
I think (and I may be wrong) that one issue here is that in JCR you cannot have both a property and a child node with the same name, so both expression cannot be true at the same time. Maybe then the evaluation of the xpath expression is assuming that, and causes the ambiguos behavior.
In fact, in JCR, the path to the property 'bar' would be /foo/bar, the same as the path to che child 'bar'.

On Tue, Feb 10, 2009 at 6:46 AM, Ard Schrijvers <> wrote:

> Hi,
> On Mon, Feb 9, 2009 at 8:17 PM, Dan Diephouse
> <> wrote:
> > This is probably a rather obvious question, but I'm trying to
> > understand the queries that Jackrabbit is putting together
> and figured
> > I'd fire off an email to see if anyone could help me out quick. My
> > xpath query is "//child[foo/@foo = 'bar']" and the lucene query is:
> > +(+(_:PROPERTIES:1:foo[bar _:PROPERTIES:1:foo[1:bar)
> +name() = {}foo)
> > +DescendantSelfAxisQuery(+ChildAxisQuery(_:PARENT:, {}testroot),
> > +name() =
> > {}child, 1)
> > Why are there two "_:PROPERTIES:1:foo[bar" ?
> those two are not identical, the second one has a '1:' before
> the 'bar'.
> because jackrabbit cannot tell whether 'bar' is a literal of
> type STRING or NAME by just parsing XPath, it simply searches
> for both occurrences. the 1 you are seeing in the second term
> is the index internal prefix for the default namespace uri.

Might this be the reason that if I do the query:


The if foo does not have a node 'bar' but a property that is called bar
and equals 'test' that I get a hit? So,


Seems to result in the same hit, where in case foo has a property
bar='test' I would only expect the second one to return a hit

Or should //foo[bar='test'] return the hit as well? I am not sure what
[bar='test'] would actually mean. In xpath it would be a child element
with text value 'test', isn't?


> regards
>  marcel