Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

[Carsten Bormann <[e-mail]>]

For those who wonder what all the fuzz in this thread is about, let me try to explain this with some different terminology, exposing what kind of intuition these widely diverging value judgements might derive from.

In programming, there are two camps: static typers and dynamic typers.  Static typers want to annotate their programs with information about the objects being manipulated so the compiler can help them catch careless mistakes even before the program runs.  Dynamic typers don't care about that as much, because they know they have to write tests anyway (not all programming errors are exposable as type errors) and these will uncover the same careless mistakes.  [The runtime system will actually check types once the specific context of execution is available, that's why it's called "dynamic typing".]

The programming debate is beside the point here for a number of reasons*), but it does shape the thinking of programmers, and it seems in particular it shaped the thinking of some of the commenters here.

/a/1/b/2 is something that a dynamic typer would come up with.  The specific semantics are well-defined, but only in the specific execution context (what JSON document this is being applied to).
/a:1/b:2 (to use James' strawman syntax that distinguishes JSON object keys from array indices) exposes more typing info, so it is more statically typed, and it will catch mismatches between the types that the JSON pointer assumed to be present and those that actually are.

For a static-typing fundamentalist, it is viscerally unacceptable to forego the opportunity of catching this kind of "type error".

For a non-fundamentalist, this is more of an issue of probabilities, and the interlocking of mechanisms.  
Which percentage of usage errors will be caught by this?
Many, many mismatches between JSON pointers and JSON instances to will just not happen to trigger this particular type error.
So it can be argued that the ability to catch it doesn't really help much: If you care about mismatch errors, you already need to have something else in place to catch them -- relying only on the likelihood of a mismatch to trigger an array/object mismatch would be imprudent. So in reality, the ability to catch the type error buys you nothing.
(Or, actually, very little, as improved diagnostics is always worth something in a debugging situation.)

TL;DR: there is no "ambiguity" at all.  Please stop referring to an "ambiguity".  There is none.
Just a missed opportunity to catch an error, caused by not sending along (redundant) type information.

(You will gather that my 2 cents for this change are "not worth it", but I was more interested in explaining the mere existence of this discussion, first.  Applying the wrong intuitions to an engineering decision is one of the major causes of suboptimal design...)

Grüße, Carsten

*) Well, for a start, we are not here to catch errors in programming.  Programming languages are difficult because they are the human interface to the computer's programmability.  JSON pointers are a pure machine-to-machine mechanism, so most of the issues in programming just don't arise.  Porting your intuitions from programming to this is not going to work very well.