W3C home > Mailing lists > Public > public-rdf-wg@w3.org > November 2011

Re: Aligning Turtle and SPARQL escape sequence processing.

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 22 Nov 2011 17:43:23 +0000
Message-ID: <4ECBDF3B.10405@epimorphics.com>
To: Richard Cyganiak <richard@cyganiak.de>
CC: RDF-WG <public-rdf-wg@w3.org>

On 22/11/11 16:56, Richard Cyganiak wrote:
> On 22 Nov 2011, at 15:56, Andy Seaborne wrote:
>> 1/ character escapes -- \t, \n \r \b \f \" \' \\
>> 2/ unicode escapes :  \u1234 and \U12345678
> …
>> Suggested changes for Turtle:
>> T1/ Allow unicode escapes in prefixed names.
> -1, I think. I don't see the use case. Allowing them in the xxx part of an xxx:yyy prefixed name strikes me as silly. Allowing them in the yyy part is weird given that all sorts of punctuation is disallowed there anyways and one can always use a<full_IRI>  if one wants to use unicode escapes. Most languages don't allow escapes in identifiers, see XML or Java.
> Same argument applies to SPARQL.
> Seriously, what's the use case?

Unicode escape allow systems to handle characters outside the range of 
the current input system and output font and it avoids risk of and not 
risk corruption (binary/text messing around).  Any unicode escape 
sequence is just a way of typing the character - it does not turn off 
special meanings unlike character escapes.

Accented characters \u00E9  é or Japanese (\u5E03\u77F3 布石).

If you have them at all anywhere, having them where the real characters 
are already legal seems consistent.  Why one place and not another?


>> T2/ Only allow character escapes in strings, not IRIs (or prefix names but they aren't allowed in them at the moment).
> +1
>> T3/ Add \f and \b character escapes.
> +1
>> T4/ Remove \>  (side effect of T2).
> +1
Received on Tuesday, 22 November 2011 17:43:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:10 UTC