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

I've tried to address this (taking into account subsequent discussion) with:
  http://trac.tools.ietf.org/wg/appsawg/trac/changeset/67

Cheers,

On 31/05/2012, at 1:45 PM, Mark Nottingham wrote:

> 
> On 03/03/2012, at 9:47 AM, Murray S. Kucherawy wrote:
> 
>>> -----Original Message-----
>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mike Acar
>>> Sent: Friday, March 02, 2012 2:35 PM
>>> To: apps-discuss@ietf.org
>>> 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/
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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