Re: Binding injection proposals

> On 2016-10-28, at 12:08, Andy Seaborne <andy@apache.org> wrote:
> 
> Peter, all,
> 

-1, in general.
any proposal which stipulates how to implement dynamic bindings in terms of any specific mechanism will be an unnecessary burden on implementations, to ensure that they produce the same side.effects and the specified incidentals.
it would be better to define the semantics for dynamic bindings in general and then leave the implementation mechanism to the implementation.

best regards, from berlin,

> How do we go about deciding when the two proposals?
> 
> I'm not unbiased - I think the "deep" implementation is better because it is less intrusive to implement, and covers more cases including ones that seem natural to me (e.g. the GRAPH).
> 
> I have a prototype implement for the "deep" implementation [1].
> 
> Also -- some tests [2] (BNodes, FILTER in EXISTS and for GRAPH, including GRAPH+FILTER).
> 
> The prototype only requires changing the execution of the "exists" function.  To implement the "top-level" proposal, requires changes at the syntax level, presumably in the translation step. Then the "Initial(t)" is in-place before translation to the algebra because the "top-level" proposal requires it to happen before filters are processed for {}-groups.  This is both more complicated and would likely impact existing optimizers for the new element that can appear.
> 
> What they do share is how injection is described. The mechanism of a replaced token in the algebra works for both.  The "deep" proposal can be implemented that way, as a rewrite of each BGP with a join to a data table (the algebra for VALUES) or rewrite each BGP with surrounding appropriate FILTER(sameTerm&&sameTerm).
> 
> The reverse is not true - the "top-level" proposal can't be explained as algebra change at runtime because "initial" must be in-place in the syntax.
> 
> 	Andy
> 
> [1] https://github.com/afs/jena/tree/exists
> [2] https://github.com/w3c/sparql-exists/tree/gh-pages/tests
> 

---
james anderson | james@dydra.com | http://dydra.com