Re: Where operation delimiters matter

On 11/03/2010 08:05, Steve Harris wrote:
> I've been playing with my Update implementation this morning.
>
> If you have a string like "CLEAR INSERT", it's not clear whether that's
> an instruction to clear the default graph, followed by an insert with a
> syntax error, or just a bogus insert.
>
> What I actually typed is "CLEAR <a>", when I meant "CLEAR GRAPH <a>".
> That parses as a "clear the default graph" operation (i.e. delete
> everything) followed by a syntax error - oops! This may be a problem
> with the parser I'm using, but I can imagine that it's hard to avoid.

My parser issues parers events at the end of each operation of the 
overall request.  It's doing one token lookahead else any thing like
"X Y*" will cause this effect.

> Syntax like "CLEAR <a> ;" would make it easier to parse as intended, but
> as a weaker alternative, having some keyword to indicate that you want
> to operate on the default graph would be safer, e.g. "CLEAR DEFAULT
> INSERT...".

While not necessary, I think it is useful to identify the default graph.

+1 (pending seeing what the overall language looks like).

	Andy

> It's possible to parse the whole update operation in one go, to ensure
> that there's no syntax errors, but that removes the point of the DATA
> keyword, which is potentially a valuable optimisation.
>
> Even in queries with no syntax errors this may be quite exciting as
> there are some fairly innocuous looking (at first glance) legal updates
> that have drastic effects:
> CLEAR DELETE DATA { <x> <y> <z> }
> I guess that's the SPARQL equivalent of
> DELETE FROM a<enter>
> when you mean to add WHERE id=23 on the end before submitting the query
 >
> - Steve
>

Received on Thursday, 11 March 2010 10:23:34 UTC