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

[Mike Acar <[e-mail]>]

On 03/01/2012 01:45 PM, Paul C. Bryan wrote:
> On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote:

>> There's also the question of JSON documents with different encodings;

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

Probably not in practice; as you and I discussed off-list, most 
implementations will not actually be working on the JSON texts themselves.

>> Another issue is that the evaluation scheme implies some application
>> semantics.

>> 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).

There is another case: What to do if a non-terminal reference token 
names a value which is not a structured type; e.g.

{ "a" : "b" }

How should you interpret "/a/c/d"? For Patch this should be an error, 
but another application might promote the value of "a" from a string to 
an object or array. If the Pointer RFC says this MAY be an error, it 
disallows those semantics.

>> 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...

-- 
Mike Acar -                                 - macar at cloudmark dot com