The `\u` escape range in Section 6.4

[xfq]

6.4 Escape Sequences
https://www.w3.org/TR/2026/WD-rdf12-turtle-20260320/#sec-escapes

Section 6.4 says \u represents a Unicode code point in the ranges U+0000 to U+D7FF and U+E000 to U+D7FF. For a four-hex-digit escape, the non-surrogate part of the BMP should be U+E000 to U+FFFF.

And there's a bigger problem: Unicode surrogates are not allowed. Allowing surrogates can cause problems with incomplete characters, but we (i18n WG) believe this issue shouldn't be resolved at the rdf-turtle level, but rather at a higher-level protocol.

rdf-turtle shouldn't prohibit surrogates, and it seems there's no such restriction in RDF 1.1 Turtle:

https://www.w3.org/TR/2014/REC-turtle-20140225/#sec-escapes

So it is also a breaking change.

[afs]

@xfq - Could you provide a link to the i18n recommendations? I am unclear what the conceptual architecture is here for "higher-level protocol".

[afs]

Data point:

RDF 1.1 does not allow an escape sequence for a surrogate in a string or IRI.
It's in the RDF 1.1 Turtle test suite.
https://w3c.github.io/rdf-tests/rdf/rdf11/rdf-turtle/#turtle-syntax-bad-numeric-escape-01

[xfq]

@xfq - Could you provide a link to the i18n recommendations? I am unclear what the conceptual architecture is here for "higher-level protocol".

I'm not an RDF expert, but here are some scenarios I can think of:

• SPARQL Graph Store HTTP Protocol can reject malformed UTF-8 or surrogate encodings before graph insertion.
• When embedding Turtle in HTML/XML/XHTML, the upper layer that can solve incomplete-character handling in the decoding/parsing stack.

I will discuss the specific scenarios in greater detail during our WG telecon this week.

[afs]

The working group discussed this in today's telecon.

The feeling was that data that conforms to the RDF 1.1 Abstract Data Model could now be written in a way that can not be handled by existing RDF 1.1 software. The majority of data from RDF 1.2 systems is expected to be fully aligned with RDF 1.1 syntax and semantics.

[afs]

I would note that xsd:string, the main form of string data in RDF, does not accept surrogates and that this outside the control of the RDF & SPARQL Working group.

[aphillips]

I was actioned by I18N to respond to this issue.

We think that the changes in this section in v1.2 are generally improvements to the text present in v1.1. The Unicode jargon is clearer and less ambiguous. Unfortunately it also exposes the problem of encoding supplementary characters (code points greater than U+FFFF).

@afs notes that xsd:string does not support surrogate code points, which is intentional and a Good Thing. However, the \u syntax has a long history, is widely implemented, and may represent a backwards compatibility problem as written in v1.2. The reason surrogate code points are illegal most places is that surrogate code units are how UTF-16 encodes supplementary characters. The \u syntax uses surrogate pairs as its means of encoding supplementary characters. The text of v1.1 might be considered ambiguous about this, even though it was not intended to be ambiguous.

Many programming languages (Java, JS, C#, python, etc.), formats (notably JSON), and utilities use or implement the \u syntax and blindly generate surrogate pairs for supplementary characters rather than using the \U syntax. Intermixing of the two escape schemes isn't perhaps that common.

Isolated surrogates (that is, surrogate code points) should absolutely be banned. Unpaired surrogate escapes should be decoded as U+FFFD (the replacement character) or generate an error. But we think your \u syntax--for compatibility with possibly-badly-implemented v1.1 processors as well as general interoperability--should allow properly formed surrogate pairs while still not permitting encoding of surrogate code points.