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:50:33 +0000
Message-ID: <4ECBE0E9.2000003@epimorphics.com>
To: Richard Cyganiak <richard@cyganiak.de>
CC: RDF-WG <public-rdf-wg@w3.org>


On 22/11/11 17:43, Andy Seaborne wrote:
>
>
> 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.

mangled:
"it avoids risk of corruption (binary/text messing around)"

> 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?
>
> Andy
>
>>> 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:51:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:46 GMT