Re: discrepancy between SPARQL and Turtle

I'm not going to lengthen the debate on an archived public list.

I've just written on the private thread asking the chairs to rule on the 
charter before we get to issues/PRs.

On 13/05/2026 14:56, Gregory Williams wrote:
> On May 13, 2026, at 2:56 AM, Andy Seaborne <andy@apache.org> wrote:
>>
>> SPARQL 1.1 is over 10 years ago. AIUI A "maintenance and new features" mode for a working group isn't any more permissive for such a change.
>>
>> As it has security implications so I hope it is in-scope for the WG similar to an errata.
>>
>> We could make the change and add text:
>>
>> * Version 1.0 and 1.1 of SPARQL accepted numeric escape sequences anywhere in the SPARQL request string.
>> * Implementations MAY accept such input, being aware of the issues this has.
>> * Systems MUST (or SHOULD?) produce text that only uses numeric escape sequences in URIs and literal lexical forms.
> 
> I worry that this isn’t a good solution.

Personally, I don't think we have to put in the suggested text - it was 
to see if we can find a widely acceptable position.

 > I see two problems with only accepting the escapes in URIs and
 > literals:

> 1. As currently specified, the un-escaping happens before parsing, so depending on the APIs being used, it can be very hard to tell if an escape is in a URI or literal.

I' not sure I follow that - the 3rd point is about writing, not parsing.

> 2. I think this would still leave the 1-char vs. 2-char issue as described previously. Just having the escapes in a literal wouldn’t change the fact that the same sequence would be expected to produce 1 char in SPARQL but 2 chars in Turtle. I would much prefer a full fix that aligned SPARQL with the semantics of Turtle, but that is a big change as it requires updating the grammar and introduces backwards incompatibility.

The grammar change is ECHAR => ECHAR | UCHAR

#ifdef ARQ
| < #UCHAR:      <UCHAR4> | <UCHAR8> >
| < #UCHAR4:     "\\" "u" <HEX> <HEX> <HEX> <HEX> >
| < #UCHAR8:     "\\" "U" <HEX> <HEX> <HEX> <HEX> <HEX> <HEX> <HEX>
<HEX> >
#endif

It is tested - ARQ does it in non-strict mode and I presume the other 2 
char systems do the same.

Turtle text: (for a literal lexical form were both kinds of escape are 
allowed):
"""
The characters between the outermost [quote]s are taken, after numeric 
and string escape sequences are replaced with the characters that they 
represent, to form the RDF string of a lexical form."

We would adopt the Turtle text. Specifically, be clear it is "replace 
escape sequences with respect to the original string" (2-char). 
Otherwise delimiter attacks are possible.

> As I said, I agree that this is a major problem. But I’m concerned that the full fix would be a backwards incompatible change introduced very late in the WG process. I can get over that concern if we’re confident it’s acceptable under our charter and there is broad agreement, but thought it was worth raising.
> 

Now this issue is on the list, I would expect W3C security review to 
pick it up, or for PA to tell them.

Box<Pandora>.as_ptr as they say in Rust.

> .greg
>

Received on Wednesday, 13 May 2026 15:16:09 UTC