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

["Murray S. Kucherawy" <[e-mail]>]

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

-MSK