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

From: Mike Acar <[email-masked]>
Date: Tue, 5 Jun 2012 11:09:51 -0700

On 05/31/2012 09:42 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> 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?

At first blush. But I think a spec that says "this can be an error or it 
can be implementation-defined" doesn't really constrain an 
implementation's behavior enough to be useful.

As Murray writes:

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

I think language that says "An application of JSON pointer needs to 
define semantics for these cases" would be helpful, maybe with an 
example for Patch.

-- 
Mike Acar -                                 - macar at cloudmark dot com

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 05 Jun 2012 13:41:30 -0700

> define semantics for these cases" would be helpful, maybe with an 

+1

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Jun 2012 08:22:15 -0700

On 31 May 2012 09:42, Murray S. Kucherawy <[email-masked]> wrote:
> 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.

I disagree with what appears to be an emerging consensus, for one
reason.  There is an inherent ambiguity in pointers that requires a
concrete document to resolve.  Numerical indices can be used in two
contexts:

  /1 => "foo"
  { "1": "foo" }
  [ "foo" ]

Without a concrete document, I can't decide what the pointer "points" at.

That said, there is no stopping someone from going off-spec.  But I'd
prefer to keep it just that: off-spec.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 06 Jun 2012 13:56:06 -0700

Can you elaborate on what the utility is of deciding what a pointer
points at without a concrete document to resolve it to?

Paul

On Wed, 2012-06-06 at 08:22 -0700, Martin Thomson wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Jun 2012 08:33:09 -0700

On 6 June 2012 13:56, Paul C. Bryan <[email-masked]> wrote:
> Can you elaborate on what the utility is of deciding what a pointer points
> at without a concrete document to resolve it to?

There are a number of applications that have been invented that use
XPath and XML to do just this.  Including, "insert new content at this
location", or "you are missing an element at this location".

But I don't think that it's wise to support those applications.  Ever.
 Even the best of these applications had major issues.  c.f. XML patch
ops, XCAP, etc...

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jun 2012 12:22:11 +1000

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:
> 
>>> 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/
> 
> 
> 

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