Re: unicode escapes in prefix names

On 23 Nov 2011, at 09:16, Andy Seaborne wrote:
> As you know, the SPARQL-WG is, by charter, strongly encouraged not to
> change SPARQL 1.0 behaviour.  Simply ignoring that doesn't really help the situation.  We have to work to improve where we can.

SPARQL 1.0 allows unicode escapes everywhere.

The current plan of the SPARQL WG seems to be to allow it nowhere except in strings, IRIs and prefixed names. This seems to be ok with the SPARQL WG's charter.

But allowing it only in strings and IRIs would *not* be ok with the charter?

That seems to be an odd place to draw the line.

SPARQL syntax is derived from Turtle. Turtle got unicode escapes right. SPARQL 1.0 chose a different design that has issues. SPARQL 1.1 should return to the Turtle design, both to fix those issues and in the name of doing the same thing in the same way across WGs. Surely it's not the *charter* that's preventing the change to SPARQL.

>> I would argue that SPARQL is changing to avoid a security risk in
>> SPARQL Update:
>> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Aug/0010.html
> 
> That message has a mistake in it.
> 
> SPARQL Query and SPARQL Update are separate languages.

Last time I checked they used the same unicode escape rules.

> The protocol provides different operations for query and update.

I believe there are endpoints that support both operations.

> You can't mix SELECT and DELETE by design.

The example in the message doesn't mix SELECT and DELETE. It has a DELETE that is obfuscated to look like a SELECT. The point is that a user could be tricked into running an operation thinking it's something completely different. This doesn't require SELECT to be harmful – you can obfuscate “DELETE everything” as “update the value of this triple there to the current date”.

> Your concerns about %-encoding, trailing dots, are well motivated but solving them is not in scope of this WG or indeed W3C as it's RFC 3986/3987 matters and DBpedia's implementation thereof.

Character escaping in IRIs is already a rather arcane subject and indeed this WG can't do anything about that – it's the world we live in and the world we have to address in the specs we define. Making it *more arcane* in Turtle – without any benefit to users – just because that would be convenient to the SPARQL WG – is not something that I will support.

Best,
Richard

Received on Wednesday, 23 November 2011 13:54:12 UTC