W3C home > Mailing lists > Public > www-international@w3.org > July to September 2012

Re: I18N-ISSUE-193: define when escapes are evaluated [TURTLE]

From: Gavin Carothers <gavin@carothers.name>
Date: Fri, 7 Sep 2012 09:34:46 -0700
Message-ID: <CAPqY83wzWjDO=Sz1FmYd9OwXxM-BNfv3FBfiMOPLBv4N2yW0Sg@mail.gmail.com>
To: Internationalization Core Working Group <www-international@w3.org>, public-rdf-comments@w3.org
On Fri, Sep 7, 2012 at 9:25 AM, Internationalization Core Working
Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> I18N-ISSUE-193: define when escapes are evaluated [TURTLE]
> http://www.w3.org/International/track/issues/193
> Raised by: Norbert Lindenberg
> On product: TURTLE
> http://www.w3.org/2012/08/15-i18n-minutes.html
> Section 6.4, both forms of Unicode escape sequence: The spec doesn't say at what stage the escape sequences are converted to their corresponding characters. Can \u0022 start or end a string literal (as it does in, for example, Java)?

No. Escape sequences occur inside literals. There is a table in 6.4
showing when they can be used. The normative processing requirements
for when things are escaped are expressed in 7.2 RDF Term Constructors
for example:

STRING_LITERAL_SINGLE_QUOTE 	lexical form	The characters between the
outermost "'"s are unescaped┬╣ to form the unicode string of a lexical

and the footnote to that table:

┬╣ section 6.4 Escape Sequences defines a mapping from escaped unicode
strings to unicode strings. The following lexical tokens are unescaped
to produce unicode strings: IRIREF, STRING_LITERAL_SINGLE_QUOTE,

Perhaps some additional language could be used in the 6.4 section
introducing escapes rather then relying on interpretation of the

> Appendix B implies that escapes are replaced with their character equivalents before document processing, but it doesn't appear to say that explicitly anywhere.

Appendix B may not be clear enough in it's Encoding considerations:
section. It may also simply be using old language. Thanks!

Received on Friday, 7 September 2012 16:35:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:01 UTC