W3C home > Mailing lists > Public > www-tag@w3.org > December 2013

Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Mon, 2 Dec 2013 19:07:30 -0500
Message-ID: <CAMm+LwhZwgrD6U=z+rEAyYD-9TK0ZNdFbmNrVSTRAdB5M2TPCQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote:
> > Since we are talking about a serialization format, the distinction
> between
> > unordered sets and lists cannot occur at the wire level and this is where
> > we need interoperation.
>
> But it can be part of the on-the-wire description.  See below.
>
> > One of the things I think we have learned from JSON is that a
> > self-describing format only needs to specify the abstract type of the
> datum
> > and not the representation.
>
> Self-description is a continuum.  Some ASN.1 encoding rules can encode
> quite a bit of a schema on the wire -- clearly there's a point at which
> the resulting redundancy causes problems.  But it's also true that
> having a large subset of the schema in the serialization can be useful
> (e.g., for generic "dump" tools).
>
> Given the prevalence of languages like Python, a "set" type will no
> doubt seem useful to some!  Heck, the ability to use non-string values
> as keys (names) for objects would be nice too -- anyone who's spent much
> time with Python and JSON has wished for these things.  JSON alone is
> insufficiently expressive for "pickling" Python values; JSON with a fair
> bit of convention layered on gets closer to being good enough for
> pickling Python values.
>

Well that is a rather different situation, the language allows for
polymorphic typing and does not have a clue what the native data type of
the entries it exchanges is.

I agree that there is a utility in that information for pickling data
values but it is not an approach I would like to see in an application
protocol.

The way I would approach this if necessary would be to add in a tag that
could be used to annotate the data with additional type hints.



-- 
Website: http://hallambaker.com/
Received on Tuesday, 3 December 2013 00:08:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC