W3C home > Mailing lists > Public > public-interledger@w3.org > November 2016


From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 3 Nov 2016 13:26:18 +0100
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: Interledger Community Group <public-interledger@w3.org>
Message-ID: <55ec068a-ea00-d037-1856-c2478a60275e@gmail.com>
On 2016-11-03 11:55, Adrian Hope-Bailie wrote:
Hi @drian,

> @anders: JSON is supposed to be self-describing.

It can only describe the core types, expanded or not.

Anyway, IMO the only thing really missing in JSON (after the arrival of ES6) is support for comments which is needed for making JSON fully useful for "config" files as well.

I think I need to implement that because it seems to be a de-facto standard these days...

 > Your tools require up-front knowledge of the expected data types using a schema or similar.

Indeed it does, OTOH what important real-world system is capable of processing arbitrary data?

FWIW, I don't personally use schemas but rather programmatic parsing:
Aided by the checkForUnread() method you can "strictify" JSON objects as much as you want.
Yes, you may even have "any" types if that is needed.

> TJSON has the advantage of still being backwards compatible with regular JSON
 > although I concede it will output some weird looking tags and values if you don't string the type annotations.

Unless you have native support for TJSON, you cannot really make full use of it.

Node.js, Browsers, Python 3.5 [-float], Go 1.7, and my java-stuff all adhere to ES6 which at least for my limited purposes is entirely satisfactory.

Maybe the requirements for Interledger are different?

Your hope stands with Mr. Laurie who works for Google.

Personally I believe CBOR (Which Google already supports) is a better alternative because it deals with object canonicalization which I couldn't find anything about in the TJSON draft 2016-10-02.


> @emile: Sorry, there were issues with the bridge. I will post the recording of the call and the one from 2 weeks ago as soon as we have upgraded our SoundCloud account (we ran out of space on the free account).
> On 3 November 2016 at 11:32, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>     On 2016-11-03 09:32, Adrian Hope-Bailie wrote:
>         For those of you that were on yesterdays call and part of the discussion around encoding formats here's a another to throw in the ring courtesy of a member of this community, Toni Arcieri.
>         https://tonyarcieri.com/introducing-tjson-a-stricter-typed-form-of-json <https://tonyarcieri.com/introducing-tjson-a-stricter-typed-form-of-json>
>         Looks like an interesting option for verbose text encoding of crypto-conditions (for dev and test)...
>     I don't see the point with introducing a version of JSON that makes strings look like "s:Hello world".
>     Wouldn't it be more logical to start over from scratch?
>     All mentioned features and some more are supported by yours truly's JSON tools on GitHub (https://github.com/cyberphone/openkeystore/tree/master/library/src/org/webpki/json <https://github.com/cyberphone/openkeystore/tree/master/library/src/org/webpki/json>) and that without changing anything in JSON.
>     Doc: http://webpki.org/papers/keygen2/doc/org/webpki/json/JSONObjectReader.html <http://webpki.org/papers/keygen2/doc/org/webpki/json/JSONObjectReader.html>
>     If you for example would like to use financial number you would use BigDecimals you would for write do
>               jsonwriter.setBigDecimal("amount", bigdecimalvalue[, decimals);
>     while reading
>               bigdecimalvalue = jsonreader.getBigDecimal("amount"[,decimals);
>     That the values are represented a ordinary JSON strings like "599.25" doesn't matter, because the parser will reject anything that doesn't fit the type in question.
>     That is, getInt("myval") would reject 1.0 because it is not an integer.
>     IMO the ES6 specification addresses canonicalization (including property order...) good enough.  Add typing on top of that and you're done.
>     Anders
Received on Thursday, 3 November 2016 12:26:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 November 2016 12:26:54 UTC