Subject: [Json] clarify decoding of JSON string escapes

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Wed, 11 Dec 2013 11:43:37 -0800

It is not completely clear how to decode the JSON string "\uD834\uDD1E"

One way would be to produce a string containing two Unicode code points.  The 
other way would be to produce a string containing a single Unicode scalar value.

It is fairly obvious that the second is preferred, and some readings of 
rdf4627bis-09 would indicate that the first is not allowed. However, the 
discussion in Section 8.2 seems to indicate that the first way could be 
permissible.

I think that it would be useful to indicate that JSON \u escapes must be 
decoded to produce Unicode scalar values wherever possible.

Peter F. Patel-Schneider

PS:  The discussion in 8.2 could be improved by talking about Unicode scalar 
values instead of Unicode characters.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 11 Dec 2013 20:03:17 +0000

>decoded to produce Unicode scalar values wherever possible.

I wanted you to be wrong, but in my re-reading of -09, I see text in
section 7 about *generating* escape sequences, but nothing about how to
parse them.  I think we would need text along the lines of:

"""
When parsing a JSON string, if an escaped lead surrogate in the range
\uD800 to \uDBFF is followed immediately by a trail surrogate in the range
\uDC00 to \uDFFF, the two escape sequences combined represent a single
Unicode code point.  Any other combination of \u escapes represent
individual code points.
"""

This could either go in section 7 or section 8.2.

>values instead of Unicode characters.

I think the intent of that section is that things that are currently
assigned characters interop much better than anything else.  As such, I
think the current language is fine.

-- 
Joe Hildebrand

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Wed, 11 Dec 2013 12:57:01 -0800

On 12/11/2013 12:03 PM, Joe Hildebrand (jhildebr) wrote:
> [...]

I agree that it is also a good idea to avoid unassigned code points.  However, 
8.2 goes on to contrast this with some talk about unpaired surrogate code 
points, which are the code points that really should be avoided.  If 
unassigned code points are also to be avoided, it would be better to have a 
second example showing this.

This is, however, a relatively minor point.

peter