Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00

["Paul C. Bryan" <[e-mail]>]

On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote:

> Hi,
> 
> I've been asked to review the JSON Pointer and Patch draft RFCs. I've 
> had some discussion about them off-list, and have been advised to bring 
> my issues to the list. And so, I am. :)
> 
> I've scanned the archived list discussion of the patch and pointer RFCs, 
> so I don't think these issues have come up here already. Let me know if 
> they have.
> 
> The first issue is comparing Unicode strings. Section 4 of 
> http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00 says
> 
>        If the currently referenced value is a JSON object, the new
>        referenced value is the object member with the name identified by
>        the reference token.
> 
> That is, if the reference token equals the name of some value within the 
> object, move to that value. However, the tokens and values are Unicode 
> strings; I'm not an expert in Unicode, but my impression is that testing 
> Unicode strings for equality is not as simple as comparing sequences of 
> bytes. For example, there are linguistic considerations: I believe 
> German ö and oe are considered identical.


While we may consider ö and oe to be linguistically equivalent, I do no
believe they are considered lexicographically equivalent in a Unicode
string comparison. Someone please correct me if I'm wrong. Would it help
to define the comparison as being lexicographical?


> There's also the question of JSON documents with different encodings; 
> UTF8 is the default, but UTF-16 and -32 with both endiannesses are also 
> supported. Presumably this question will disappear in practice, since 
> implementations will operate on deserialized data structures, not on 
> JSON texts.


Since they're logically the same underlying Unicode representations, I'm
not sure there's any issue to consider here.


> Could somebody with more expertise in this area comment? Perhaps this is 
> all a solved problem, and the Pointer RFC simply needs to pick a 
> normalization method and equality definition - or perhaps it's all so 
> well-settled I'm seeing a problem where there is none.
> 
> Another issue is that the evaluation scheme implies some application 
> semantics. Again, section 4:
> 
>     If a reference token is being evaluated against a concrete JSON
>     document, the implementation MAY evaluate each token against a
>     concrete value, and terminate evaluation with an error condition if a
>     evaluation fails to resolve a concrete value.
> 
> It's easy to imagine a case where a Pointer refers to a deep hierarchy, 
> e.g. /a/b/c/d, and the application semantics of following it are to 
> create automatically any non-existent intermediate objects.
> 
> My initial thought was that the Pointer RFC should explicitly say that 
> specs which use it (e.g. Patch) should define semantics for ambiguous 
> cases (non-unique or non-existent member names, array index out of 
> bounds, etc). That can still result in a user of Pointer having to 
> implement it himself, if there are no implementations which offer him 
> precisely what he needs.
> 
> Is it preferrable to explicitly say "You must make these decisions for 
> your use case" instead of "Behavior in these cases is undefined"?



I'm not sure. I'm open to suggestions from the apps working group...

Paul