Code change:
3.8. <del> A Normalized Path is a JSONPath with restricted syntax that identifies a node by providing a query that results in exactly that node.  For example, the JSONPath expression "$.book[?(@.price<10)]" could select two values with Normalized Paths "$['book'][3]" and "$['book'][5]".  For a given JSON value, there is a one to one correspondence between the value's nodes and the Normalized Paths that identify these nodes.  Note that there is precisely one Normalized Path that identifies each node. A JSONPath implementation may output Normalized Paths instead of, or in addition to, the values identified by these paths. Since bracket notation is more general than dot notation, it is used to construct Normalized Paths.  Single quotes are used to delimit string member names.  This reduces the number of characters that need escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts. </del> <ins> A Normalized Path is a canonical representation of the identity of a node in a value.  Specifically, a Normalized Path is a JSONPath query with restricted syntax (defined below), e.g., "$['book'][3]", which when applied to the value results in a nodelist consisting of just the node identified by the Normalized Path.  Note that a Normalized Path represents the identity of a node .  There is precisely one Normalized Path identifying any particular node in a value. A canonical representation of a nodelist is as a JSON arrays of strings, where the strings are Normalized Paths. Normalized Paths provide a predictable format that simplifies testing and post-processing of nodelists, e.g., to remove duplicate nodes. Normalized Paths are used in this document as result paths in examples. Normalized Paths use the canonical bracket notation, rather than dot notation. Single quotes are used to delimit string member names.  This reduces the number of characters that need escaping when Normalized Paths appear in double quote delimited strings, e.g., in JSON texts. </ins> Certain characters are escaped, in one and only one way; all other characters are unescaped. <del> Normalized Paths are Singular Paths.  Not all Singular Paths are Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </del> <ins> Note: Normalized Paths are Singular Paths, but not all Singular Paths are Normalized Paths.  For example, "$[-3]" is a Singular Path, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </ins> Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not. So the definition of "normal-hexchar" is designed for hex escaping of characters which are not straightforwardly-printable, for example <del> U+000B LINE TABULATION, but for which no standard JSON escape such as "n" is available. </del> <ins> U+000B LINE TABULATION, but for which no standard JSON escape, such as "n", is available. </ins> 3.8.1.

Related discussion:
text: For instance when the SomeTool processor outputs a number 42 and the options are that it represents any base in which the symbols are generally valid (per consensus) to me would rather raise questions than answer them. I would expect these complication (extra dimensions) less inside a format but more in a "processor" role or protocol description. The latter describing expected behavior within the dynamics of some interchange. I used the term without caution. Sorry for that. In my reading of the sentence we discuss about, the consumer of such a result has to look elsewhere to find out what the processor provides as result, right? That is our normal task as tool users. However, I think we better try to not bring in such ambiguities without noting the reason outside of our mandate to change. Maybe note, that existing processors (or however we like to call these providers of jsonpath responses) display mixed behaviors (what you call options). Makes sense? If not, sorry for the noise.
Well, we do say: I wouldn't go so far to say that the Normalized Path is "contexted". You need the value to compute the Normalized Path from the query, but after that, it doesn't require context to apply it (well, they are meant to be applied to that value, but they are regular JSONPath queries). With IETF 115 raging and Glyn being offline for a couple of days, we'll probably not respond very fast the next few days; I think good points are being made here even it is not always clear how to modify the text further to fully reflect them.
I believe the PR now makes this property of Normalized Paths clear. (I'd prefer not to labour the example.)
NAME I have attempted to address your concern by making the following general statement (suggested by NAME Normalized Paths. A nodelist is defined as follows (in the Terminology section): From this, it is clear that an implementation of JSONPath may output a nodelist as a JSON array of strings, where the strings are Normalized Paths. So I have deleted the following statements, which seemed to be causing confusion: Normalized Paths instead of, or in addition to, the values identified by these paths. For example, the JSONPath expression could select two values and an implementation could output the Normalized Paths and .