Hi Mary,
Thanks for joining in.
> Talk of fragment roots is a bit of a red herring. The point
> is that the two expressions are asking different questions
> and that is why you are seeing different results.
Yes. Obviously I must have been jumping to wrong conclusions here. It looked
like the perfect explanation for Vivek's problem. Sorry..
> Looking at the other expression, the doc()//para as the first
> argument to cts:search means evalate doc() (everything
> document in the database) and then evaluate //para in the
> context of that set (all the para elements in the database).
> We'll actually evaluate this with indices for efficiency, but
> that's the semantics
> of the expression. Then, in the context of this set of para
> elements,
> evaluate
> the query, returning only those para elements that match it.
Though, it was my impression searching follows a slightly different set of
rules:
1. Find matching *fragments* using indices
2. Filter out false positives
It looks like it slipped my mind that the searchable xpath can be seen as a
filter as well..
Below a few test cases that might shed some light on this for everyone. Thanks
Douglas, I took your test case and only added a false positive match to it..
Take an empty database and insert the following test documents:
<doc>
<foo>1</foo> <-- the false positive candidate
<para>
<foo>2</foo>
</para>
</doc>
<doc>
<foo>2</foo>
<para>
<foo>1</foo> <-- the real candidate
</para>
</doc>
Calling the search:
cts:search(fn:doc()//para, cts:element-value-query(xs:QName("foo"),
"1") )
Results as expected:
<para>
<foo>1</foo>
</para>
Counting result:
count(cts:search(fn:doc()//para,
cts:element-value-query(xs:QName("foo"), "1") ))
Returns as expected:
1
But count is slow, so one would prefer using xdmp:estimate:
xdmp:estimate(cts:search(fn:doc()//para,
cts:element-value-query(xs:QName("foo"), "1") )),
Unfortunately this returns:
2
I can only explain this when the query is executed on fragments, not on a para
node set. Calling cts:search directly is applying filtering of false positives,
but using xdmp:estimate apparently not.
Using cts:remainder, which seems to respects the filtering option of
cts:search, this can be demostrated more closely:
cts:remainder(cts:search(fn:doc()//para,
cts:element-value-query(xs:QName("foo"), "1") )[1]),
Returns as expected:
1
Passing an explicit 'unfiltered' option to cts:search, returns what
xdmp:estimate is returning as well:
cts:remainder(cts:search(fn:doc()//para,
cts:element-value-query(xs:QName("foo"), "1"), "unfiltered")[1])
Returns:
2
I actually believe cts:remainder doesn't respects the filtering option at all,
so the last two test cases might be unrealiable..
Cheers,
Geert
Drs. G.P.H. Josten
Consultant
http://www.daidalos.nl/
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel.: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
http://www.daidalos.nl/
KvK 27164984
De informatie - verzonden in of met dit emailbericht - is afkomstig van
Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit
bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit
bericht kunnen geen rechten worden ontleend.
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
