[Mulgara-dev] xsd resolver

[Life is hard, and then you die]

I realized an interesting little detail about the xsd resolver (and
our topaz string-resolver, since it shares the same design) while
doing some testing. Specifically, now that the lucene-resolver can
return scores, I was playing with limiting the returned results to
those with a minimum score, like so:

  select ... from ... where
    $s <mulgara:search> $srch in <lucene> and
      $srch <foo:bar> 'term' in <lucene> and
      $srch <mulgara:score> $score in <lucene> and
    $score <mulgara:gt> '0.5'^^<xsd:double> in <sys:xsd>;

However, this always returns 0 results, even if there are scores above
0.5.

Digging into this a bit, the "problem" is that the xsd resolver does a
findStringPoolRange() to find all items in the stringpool that match
the condition (i.e. all doubles in the stringpool with a value greater
than 0.5, in the above example); the resulting list of tuples is then
joined against the tuples returned by the lucene-resolver. Of course,
the chance of the stringpool happening to have a value that's the same
as a score is extremely small, and hence the join usually returns no
results.

This leads me to wonder if A) the xsd-resolver shouldn't instead be a
filter rather than a generator of tuples, or B) if we should create
additional predicates that result in filtering instead of lookup. I
suppose a third approach might be C) try to determine if the subject
is bound elsewhere in the query and use lookup if not and filtering if
so - I'm not sure if this is fully feasible at this point, but I don't
have a full enough understanding of the Annotations yet (which I
presume is at least part of the mechanism for this sort of stuff).

Any thoughts?

Btw., this problem relates to any resolver that can generate tuples of
values not stored in the stringpool, such as the http-resolver and
file-resolver.


  Cheers,

  Ronald