[Mulgara-dev] xsd resolver

[Paul Gearon]

On Wed, Nov 12, 2008 at 4:11 AM, Life is hard, and then you die
<ronald at innovation.ch> wrote:
>> You're right, we need filtering - but only when comparing to variables
>> that were bound by something other than the data pool. Of course,
>> SPARQL already does this, but that's not the point here.
>
> But the SPARQL implementation _always_ does filtering, which isn't
> great either.

No, SPARQL lets you choose which one you want. If you want to filter,
then you use FILTER. If you want to talk to the XSD resolver, then you
say "GRAPH sys:xsd {....}"

>> Second, I believe that any numbers generated in a query will have a
>> negative gNode (are you able to check this?). Perhaps it's possible to
>> filter on these numbers, while still matching on positive gNodes?
>
> Yes, they are negative. But I'm not sure how that helps: the decision
> whether to generate or filter needs to be done ahead of time, or else
> we have to tell the query scheduler that the xsd resolver always be
> run last.

Since this problem could happen at any time, then I think we have to
make this guarantee (that the xsd resolver be run last). I recall that
Andrae knows how to force this. Andrae?

> Hmm, I think the DefinablePrefixAnnotation can be used to determine
> whether the variables have been bound or not, i.e. that could be used
> to trigger whether to filter or generate. However, I think one piece
> is still missing: a way to the query planner that it should use other
> resolvers to resolve the variables _if possible_ (the
> MandatoryBindingAnnotation doesn't cut it because that's a hard
> requirement rather than a soft please-but-only-if-you-can). So maybe a
> new annotation is needed here.

Yup, I'm definitely going to bring Andrae into this conversation....

Paul