Re: updated draft

On 02/04/17 10:07, james anderson wrote:
> good morning;
>
> i read through the first section of the draft.
> i note, that it purports to "records community consensus”.
> however that consensus is to be established, i dissent from the current proposal.
> significant aspects of the proposal do not make sense.
> some are unclear and others are wrong.
>
> 1.1 should be reordered such that the more complete explanation dominates the examples.
>
> 1.2 states as a problem something which is just a restatement of a language restriction.
> whatever problem that causes in whatever evaluation model is presumed, the problem statement should be complete.
> the paragraph which describes the affected forms includes “bound”, but the text does not motivate that.

Your comments on 1.1 and 1.2 are about the style? There is one 
motivating example of one place the problem can occur then more complete 
description.

You want a description then complete set of examples?  Could you suggest 
some more examples?

This is work-in-progress and only mentioned as it had been referenced 
elsewhere.

For 1.2 - yes it is a language restriction from the evaluation 
requirement that SPARQL is single-assignment per row.

What do you suggest as a problem statement?

>
> 1.3 the problem statement suggests a manner of manipulating types in its execution model which cannot be valid and operations would not carry sufficient state.
> the next paragraph presumes an execution model which cannot be correct -  as the paragraph itself implies, and the subsequent commentary demonstrates.
> the proposal reads as if it relies on this model to the exclusion of others.
> that is unfortunate and deserves more extensive explanation and justification
> to the extent that this errata report relies on this execution model without make it explicit, the report itself is deficient.

We have covered this elsewhere.

Our starting point is what the SPARQL 1.1 spec says and here what it 
says has unintended consequences.

>
> 1.4 so far as i can follow the description, this problem is a consequence of following the (not completely comprehended, but evidently deficient) execution model suggested by 1.3

The issue with MINUS is to do with the execution of the MINUS form. It 
is an anti-join so the variables from left and right hand sides (LHS and 
RHS) matter.  It is complicated by the special rule for MINUS for the 
case of no shared variables; we have to work with what the spec on that.

The spec changes MINUS because variables are removed by substitution.

Both proposals A and B change the variables shared between the LHS and 
RHS of MINUS, in different ways.  It is an interesting point as to what 
MINUS is likely used for inside EXISTS.

1.4 should converted to have an example and explanation.

Personally, I rate the effect on MINUS is more minor issue as it is 
uncommon and whatever proposal a system uses, something changes.

> you are trying to define a method to permit an implementation to follow an execution model which is deficient.
> the reference to 18.6 is not a live link, but i understand it to refer to the definitions for “substitute” and “evaluation of exists”.
> to the extent that i comprehend the arguments in this report, they follow from an interpretation of those passages to require a lexical transformation at a specific point in the query interpretation.
> those constraints do not follow from the text and entail a combination of types which is sufficiently improbable and difficult to engineer, that any argument, that the text might somehow require it, does not convince.
> a more successful approach could be, not to change the language definition to permit an implementation based on that execution model to produce a “correct” result, but to abandon that model and adopt one which permits an interpretation of the existing text to produce the “correct” results.
>
> i did not re-read the proposals.
> as i have explained before and have reiterated here, they demonstrate an approach which possesses such inherent flaws that it makes little sense to explicate the problems in the detailed realization.

You have asked, I think, for a dynamic bound execution style. Proposal B 
is that (c.f. correlated subquery from SQL) and, to a large extent so is 
proposal A.

Without a "proposal C" we can use to run against the test cases it is 
difficult to know how to proceed.

     Andy

>
>
> best regards, from berlin,
>
>> On 2017-03-31, at 06:12, Andy Seaborne <aseaborne@topquadrant.com> wrote:
>>
>> It's up to date.
>>
>> If you edit the git document, it is immediately accessible at w3c.github.io (Github pages)
>>
>>    Andy
>>
>> On 31/03/17 00:34, Peter F. Patel-Schneider wrote:
>>> I updated the draft to include both proposals but I don't know how to get it
>>> to https://w3c.github.io/sparql-exists/docs/sparql-exists.html
>>>
>>> peter
>>>
>>
>>
>
>

Received on Thursday, 6 April 2017 14:41:11 UTC