- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Tue, 12 May 2026 18:02:59 +0200
- To: thomas@pellissier-tanon.fr, public-rdf-star-wg@w3.org
Thanks to you both. I was suspecting that this "discovery" of mine was actually old news for others :) +1 to what Andy wrote and to "fix" SPARQL 1.2. pa On 12/05/2026 17:39, thomas@pellissier-tanon.fr wrote: > +1 to Andy. > > Oxigraph also consider it as a string of length 2 except if a compile time option is set and then it's 1 just like the spec. > > Like Andy said, my rational is also to avoid obfuscation attacks and similarly to Jena, I never got any feedback/complain about it. > > I am also in favor of changing the behavior. I don't see any upside with the current SPARQL behavior. > > Thomas > > -------- Original Message -------- > On Tuesday, 05/12/26 at 12:47 Andy Seaborne <andy@apache.org> wrote: > On 12/05/2026 10:54, Pierre-Antoine Champin wrote: >> * Jena, ... consider it as a string of length 2 > Not quite. > > With SPARQL 1.2 strict syntax, it's 1. > In general use syntax, it's 2. > > This has not been a problem, probably because \ does not need to be a > numeric escape. > > This reflects earlier discussions and a sense then that the Turtle way, > including limiting escape sequences replacement in URIs and literals is > better. > > https://github.com/w3c/sparql-query/issues/164 > https://github.com/w3c/rdf-tests/pull/151#issuecomment-2446744098 > https://github.com/w3c/rdf-tests/tree/main/sparql/sparql12/codepoint-escapes > > Unrestricted \u allows for obfuscation attacks. > I think we should change it. > > The fact that there is variability across systems suggests to me that > the impact is low. > > Others will argue for perfect compatibility. > > Andy > > > >
Received on Tuesday, 12 May 2026 16:03:01 UTC