[apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00]

[Mark Nottingham <[e-mail]>]

On 03/03/2012, at 9:47 AM, Murray S. Kucherawy wrote:

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Acar
>> Sent: Friday, March 02, 2012 2:35 PM
>> To: [e-mail]
>> Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00
>> 
>>>> 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.
> 
> I don't agree that MAY disallows anything, but I do think the current expression is too mushy.
> 
> I think it's fine for the pointer document to say that the handling of such cases is application-specific, but it should actually say that, perhaps by using your two examples to illustrate how different applications using the pointer specification could behave.


This is <http://trac.tools.ietf.org/wg/appsawg/trac/ticket/5>.

It seems like we need to add language stating that failing to match a particular token can be considered an error, or can be used by a particular application to effect some other behaviour. Make sense?

That said, personally I think of JSON-Pointer as a way to find a node in a current document, *not* a way to manipulate that document, and I'm not sure overloading its semantics are a good thing.

Cheers,

--
Mark Nottingham   http://www.mnot.net/