Re: updated draft

good morning;
[resent to include 1.5]

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.

1.3 the problem statement suggests a manner of manipulating types in its execution model which cannot be valid and operations which 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.

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

1.5 the same objection applies here as to 1.4

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.


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 Sunday, 2 April 2017 09:30:49 UTC