- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 22 Nov 2011 17:50:33 +0000
- 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 UTC