Hi Ivan.

Thanks for the quick response.
So the problem is related to the sparql expresions parser.

I think the change of the rule of this parser it should be consistent with
the definition of the others elements on the sparql expresion in order to
obtain a coherent behaviour.

For example, I think a user expect that if can be used external variables to
fix a value of a subject, predicate, etc. Also is expected to do it on the
offset, limit, etc.

I understand that to change the rule
OffsetClause   ::=  'OFFSET' INTEGER
to
OffsetClause   ::=  'OFFSET' expression

It would be solve my problem, but I dont know if this is consistent with the
rest of the elements.
Maybe there is more particular types of expresions that are allowed for
those elements (such subject or predicate). I think it sould be use the same
type of rule in the case of the offset and maybe what you seggest it is, I
dont know.


Best.
Z



On Thu, Jan 21, 2010 at 6:37 AM, Ivan Mikhailov
<imikhai...@openlinksw.com>wrote:

> Hello Ricardo,
>
> > for(sparql select
> > ...
> >   order by desc(?relevance) limit 50 offset ?:offsetValue
> >     ) do {
> > ...
> > }
> > ...
> >
> > Its warn.
> > syntax error at '?:offsetValue' at ')' before 'do'
>
> In original SPARQL the syntax was
> [19]    OffsetClause      ::=   'OFFSET' INTEGER
>
> and I did not extend it to something like
> [19*]  OffsetClause   ::=  'OFFSET' expression
>
> because in that time I was unable to efficiently prohibit bad things
> like an offset expression that depends on result values. You're the
> first who ask about the extension and it can be implemented now, so
> expressions will be permitted in the next version. Chances are that you
> can get a patch even before that if you specify the exact version you
> want to see patched.
>
> Best Regards,
>
> Ivan Mikhailov
> OpenLink Software
> http://virtuoso.openlinksw.com
>
>
>

Reply via email to