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

[Hector Santos <[e-mail]>]

Thanks Carsten for your explanations.  As having experience with both 
styles of programming as you describe and also interpretive vs p-code 
vs static compiler writing for our servers and clients, it would seem 
to me that if the both syntaxes are possible, then the solution is 
more implementator specific. In other words, implementators can deal 
with both if robustness is desired.  It sounds "kludgy" but it sounds 
like there exist both styles in practice already, so unless breaking 
existing implementators is not a concern in the name of going with the 
"correct and prefer" syntax, then both need to be supported.

The first thing that came to mind when this interesting thread started 
is whether a solution is desired for a public open-ended query 
client/server system versus this being more proprietary (presuming the 
idea of "patching" is an high authentication required concept).  It 
would seem to me that they might be various clients used against a 
server and it would be up to the server to support all possibilities 
to remain robust.   The client itself is probably having its "JIT" 
(Just-In-Time) parsing/compiling/error trapping, etc or it might be 
more static to catch canned solutions.  The client can perhaps have 
all its data I/O resolved by the "ide" new JSON support for data C/S 
(including "AJAX") transactions.  Come to think to it, the server 
implementation itself COULD have its syntax checking before release 
the page for production and/or if dynamically generated then it would 
probably use a preferred syntax.

It seems the answer is to support both syntaxes IFF there is compiler 
or interpretation logic capability to trapping both and if there are 
already existing clients and servers, note (highlight) that servers 
|need to|SHOULD| be ready for both.

I will say one thing, if we ever needed a HTTP based patching need or 
requirement to add support to our product web server component, it 
doesn't seem I have any choice - it would be prudent to support both 
especially on the client side.  What method I would use for our own 
data exchanges may be preferred method, but the server would need to 
do both.

--
HLS


Carsten Bormann wrote:
> 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.
> 
> 
> 

-- 
HLS