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

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 13:45:32 +1000

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

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Acar
>> Sent: Friday, March 02, 2012 2:35 PM
>> To: [email-masked]
>> 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/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 31 May 2012 16:42:56 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Nottingham
> Sent: Wednesday, May 30, 2012 8:46 PM
> To: IETF Apps Discuss
> Subject: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00]
> 
> 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?

I think the right approach is to say explicitly in pointer that it's left to the application using pointer to decide whether a match failure is an error or should be handled in some other way.  There are some cases where one might abort totally, or might create the path being referenced.  Patch could, for example, abort on a "change" instruction that references a nonexistent token, while "add" referencing a nonexistent token could create the intermediate objects needed to contain the new token.

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

I agree with you there.

-MSK