W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2017

Re: Language maps and undefined language

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Fri, 14 Apr 2017 10:58:25 -0400
To: Jakob.Voss@gbv.de, Gregg Kellogg <gregg@greggkellogg.net>, Robert Sanderson <azaroth42@gmail.com>
Cc: Linked JSON <public-linked-json@w3.org>
Message-ID: <2afb096a-4da8-82c3-791e-9224f0c98546@digitalbazaar.com>
On 04/13/2017 06:32 AM, Jakob Voß wrote:
> Hi again,
> Rob wrote:
>>> Note that we cannot use "", as noted, because PHP does not support
>>> empty string as the key of a dictionary... and thus we fallback to
>>> using "und”.
> "" is a legal object key in JSON and PHP just happens to be one
> programming languages with full support of JSON, so why design JSON-LD
> with focus on a particular choice of implementation in PHP? The language
> can deal with "" keys in JSON data pretty well:
> <?php
> $json = '{"":1}';
> $data = json_decode($json, true);
> echo $data[""]; # prints '1'
> ?>
> If you prefer PHP objects over PHP arrays, the "" can internally be
> replaces by another special value but that's a personal choice of
> implementation and out of the scope of JSON-LD.

I don't remember all of the implementation trouble related to the use of
empty strings in PHP, but I do remember it being more complex than is
being hinted at here. I'm pretty sure that you can't use PHP arrays
because you lose the ability to easily distinguish between arrays and
objects, which is a requirement for proper implementation.

In any event, how difficult it is to implement a syntax's processing
rules in common programming languages should absolutely be a factor in
related design decisions -- otherwise adoption could be harmed in a
significant way.

It would indeed be nice if there were no issue here, but, unfortunately,
I'm not yet convinced that's true. My memory is that the two PHP
implementers agreed that this was a pain point worth avoiding. If we can
get a new implementer to step forward (or PRs to the existing
implementations) that clearly demonstrate that this problem can be fully
avoided without serious detriment to performance or significantly
increased implementation complexity, then I'll agree that we should no
longer consider it when making future design decisions.

Dave Longley
Digital Bazaar, Inc.
Received on Friday, 14 April 2017 14:58:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:49 UTC