Re: TJSON

CBOR was also part of the discussion yesterday, the conclusion was that a
self-describing syntax like CBOR (or TJSON) is probably not a good idea for
the canonical representation of the data structures vs ASN1 which
(especially when combined with OER encoding) has the advantage of being
efficient and quite simple.

We also felt that while the direction the technology community is going
using self-describing syntax is appropriate for Web technology that is not
necessarily true for lower layers of the stack (which is where we think ILP
sits).

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 :)



On 3 November 2016 at 14:26, Anders Rundgren <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/c
> ommon/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>>
>> 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/JSONObj
>> ectReader.html <http://webpki.org/papers/keyg
>> en2/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("amou
>> nt"[,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
>>
>>
>>
>