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