Re: comment on CR 10.1 "solution sequences and result forms"

Fred Zemke wrote:
> 
> 
> 
> Seaborne, Andy wrote:
> 
>>
>> Fred Zemke wrote:
>>
>>>
>>>
>>> 10.1 Solution sequences and result forms
>>> The proposed order for processing LIMIT and OFFSET seems
>>> counterintuitive.  Suppose the solution sequence has solutions
>>> (S1, S2, ..., S9).  Suppose the user asks for LIMIT 3 and OFFSET 4.
>>> With the current rules, LIMIT 3 will truncate the solution
>>> sequence to (S1, S2, S3) and then the offset is greater than the
>>> number of solutions so the final result is empty.  Instead,
>>> in this scenario, I think the user expects to get (S5, S6, S7).
>>> Thus the offset should be applied first, reducing the solution
>>> sequence to (S5, S6, ..., S9), and then the LIMIT should be
>>> applied.  From this standpoint, the BNF for SolutionModifier
>>> should be rearranged to put OffsetClause ahead of LimitClause.
>>>
>>> Fred
>>
>> I agree the correct processing order is OFFSET then LIMIT.  The 
>> document text order follows the syntax.  
> 
> That's not what I read, in at least three places:
> 1. The box "Definition: Solution sequence modifier"
> 2. The last numbered list before 10.1.1 "Projection"
> where item 4 is LIMIT and item 5 is OFFSET and the last sentence says
> "applied in the order given by the list."
> 3. Section 10.1.4 "LIMIT" is before 10.1.5 "OFFSET".

I agree we will make it consistent and that conceptually the processing is 
that OFFSET is the start of the results, LIMIT the the maximum number of items 
returned from that offset.

The issue is that the syntax is in keeping with current SQL systems which has 
the order LIMIT then OFFSET.

I propose that:
1/ The text describes the process in conceptual order (offset first, then limit)
2/ we keep the syntax in line with current SQL practice.

> 
>> What's the correct SQL syntax here?  
> 
> There is no standard yet though one may emerge later this year.
> At this point there is only talk of limiting the results, not
> offsetting in the results.  Products vary in syntax.  I don't know 
> whether they
> vary in semantics as well.  My own product does not have this
> (to my knowledge, though outsiders frequently find things in our manuals
> that I was not aware of).
> 
>> Do SQL queries have to be in the order
>>
>> SELECT  ...
>> LIMIT ...
>> OFFSET ...
>>
>> I checked Oracle, PostgreSQL and MySQL - their documentation says this 
>> is the only allowed order in the syntax.
>>
>> This is what the SPARQL spec currently follows and the text in section 
>> 10 reflects that order.
>>
>> [We could allow both orderings in the grammar and reorganise the text 
>> in section 10 to put OFFSET processing more clearly before LIMIT.]
> If we allow both orderings, then I hope you mean that they would be 
> applied in
> the order the user specifies.  Ie, if the user writes LIMIT n OFFSET m
> then the sequence is truncated after the n-th and before and including 
> the m-th,
> leaving the (m+1)-th through the n-th.

As I understand it, that is at odds with SQL practice so I think it would be 
confusing.  I have checked a number of SQL systems and they do seem to do the 
the same thing.

> If the user writes OFFSET n LIMIT m then the sequence is truncated
> before and including the n-th and after the (n+m)th in the original 
> numbering,
> leaving the (n+1)-th through the (n+m)th.
> I am using 1-relative ordinals here.

Yes - agreed.  Items are numbered from zero.  OFFSET 1 is from the second item 
in the sequence i.e. offset counts the number of items to be skipped.

> 
> Fred

	Andy

Received on Monday, 12 June 2006 14:34:55 UTC