Add syntax tests for codepoint escaping.

[kasei]

Adds new tests for some interesting cases of unicode codepoint escaping, addressing w3c/sparql-query#164. Two tests (codepoint-esc-01 and codepoint-esc-10) are marked in the manifest with TODO markers as being dependent on decisions on how systems should handle invalid escape sequences. I believe the others are accurately test the existing spec text of SPARQL 1.1.

I think many of these cases should also be turned into evaluation tests, to ensure the unescaping is being performed correctly, but I'll leave that for another PR (or a subsequent update to this PR).

[gkellogg]

If you create the branch for the PR in the rdf-tests repo, the automatic report generation should work properly. It's conceivable that there is a different package that allows pushing the changes to a remote repo, or some filter that would prevent running that action if the repo is not local.

[afs]

Turtle handles Unicode escape sequences differently - it has UCHAR in the grammar and it can occur only in strings and URIs. Personally, I think this is a better design - a more common pattern, and it makes it clear what happens when the codepoint itself is meaningful near an escape sequence. I believe this should be "good practice".

The fact that obfuscated queries can be written in SPARQL is not good.
\u0041\u0053\u004B\u0020\u007B\u007D (codepoint-esc-09.rq) (that's ASK {})

And it is bad for streaming (SPARQL Update more than SPARQL Query).

The text 19.2 Codepoint Escape Sequences isn't precise how replacement happens. These are errata that need to be addressed in the spec..

We could split tests into two: "what we want", that is good practice (to be agreed), and "full spec".

Surveying existing systems:

• Codemirror/YASGUI for SPARQL does not seem to support this.