Where operation delimiters matter

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.

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...".

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

-- 
Steve Harris, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44 20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Thursday, 11 March 2010 08:06:25 UTC