Re: TJSON

On 2016-11-03 14:28, Adrian Hope-Bailie wrote:
<snip>

Hi Adrian,

> My thinking is to describe how one might encode something like crypto-conditions
  > using TJSON just for the purposes of having nice human readable testing data. Clearly you think plain JSON is good enough :)

Well, just to round out my take on this topic, I have no "issues" with typed properties
and self-describing data, it rather the fact that you overlay app-specific types
on core types which in the end makes naming more critical for human consumption than
the actual type.

When I started programming (sometimes in the late stone-age...), you were supposed
to use https://en.wikipedia.org/wiki/Hungarian_notation
but it seems to have gotten out of fashion.

Related: The IETF-JOSE folks obviously doesn't appreciate human readable JSON :-)

Anders


>
>
>
> On 3 November 2016 at 14:26, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     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:
>     https://github.com/cyberphone/saturn/blob/master/resources/common/org/webpki/saturn/common/PaymentRequest.java <https://github.com/cyberphone/saturn/blob/master/resources/common/org/webpki/saturn/common/PaymentRequest.java>
>     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.
>
>     Anders
>
>
>
>         @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> <mailto: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> <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> <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> <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 13:55:27 UTC