RFC Errata
Found 2 records.
Status: Reported (1)
RFC 6901, "JavaScript Object Notation (JSON) Pointer", April 2013
Source of RFC: appsawg (app)
Errata ID: 5745
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sven Willenbücher
Date Reported: 2019-06-04
Section 5 says:
The following JSON strings evaluate to the accompanying values:
"/i\\j" 5
"/k\"l" 6
It should say:
The following JSON strings evaluate to the accompanying values:
/i\j 5
/k"l 6
Notes:
In JSON itself some special characters like the backslash and the double quote character can be escaped using a backslash. A similar escaping was not described for JSON pointers. Therefore it is not clear to me why such an escaping is needed in JSON pointers too. Maybe the additional double quotes around the example JSON pointers enforce this. In the corrected text I have stated my view on this.
Status: Rejected (1)
RFC 6901, "JavaScript Object Notation (JSON) Pointer", April 2013
Source of RFC: appsawg (app)
Errata ID: 3981
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Phillips
Date Reported: 2014-05-06
Rejected by: Barry Leiba
Date Rejected: 2014-05-07
Section 3 says:
See Notes
It should say:
The following two examples from section 5 are different: Original: "/a~1b" Proposed: "/a//b" Original: "/m~0n" Proposed: "/m~n" The other examples are the same.
Notes:
The escape syntax seems weird and confusing. Rather than ~0 and ~1, why not use a repeated (double) slash to escape a slash? This is similar to how SQL escapes single quotes in string literals by using the single quote twice.
We have JSON functions in Presto (prestodb.io) that could benefit from an improved syntax (they currently use JSONPath), but I can't see understanding ~0 and ~1.
--VERIFIER NOTES--
This is a change request, not an errata report. The suggested change isn't directly acceptable, but could well be useful input into a new version of the specification. In any case, it's not addressing an error, but a feature change.