underspecified lexical-to-value map for rdf:JSON

[pfps]

The lexical-to-value mapping does not specify the result of the map for Objects, Arrays, Strings, or Literal Names. For example, the literal name true could be mapped to any of true, false, or nil. For another example, there is no description of how JSON character escapes are handled. The JSON string "\u1234" could be mapped to the value "A" and still be compliant with the lexical-to-value mapping.
email to Steve

[gkellogg]

The definitions for L2V for strings and JSON literals is brief and to the point.

Saying that a JSON string is mapped to an (RDF) string implicitly relies on the definition of a JSON string where escapes are part of the JSON encoding and not the value represented by the string. We could add something like "A JSON String is mapped to a string after processing any escape sequences". This is similar to wording in Turtle. Otherwise, we could create an algorithm that iterates over each character of the JSON string and appends the appropriate code point to the target RDF string. I consider this to be overkill.

The point "A JSON literal name is mapped to true, false, or null." implies that a JSON true is mapped to an INFRA true. Sam for false and null. We don't spell out that true maps to true, false maps to false, and null maps to null, but any other interpretation would be nonsensical.

Concrete suggestions for wording changes would be useful.

[pfps]

Standards need to be explicit. Relying on something that readers might read into the wording is not acceptable. This is especially true for strings where JSON uses an unusual escape mechanism.

[pfps]

Concrete suggestions for wording changes would be useful.

OK. Remove the section on rdf:JSON.