Re: TJSON

FWIW we find that plain old JSON + a JSON Schema definition that can act as
a input to a validator (such as ajv [1]) is fine for actual testing.  For
human readable in specs, ASN.1 is fine... so is prose if it is precise
enough.

[1] https://github.com/epoberezkin/ajv

On Thu, Nov 3, 2016 at 8:54 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> 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/c
>> ommon/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@gm
>> ail.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/introd
>> ucing-tjson-a-stricter-typed-form-of-json <https://tonyarcieri.com/intro
>> ducing-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/keyge
>> n2/doc/org/webpki/json/JSONObjectReader.html <
>> http://webpki.org/papers/keygen2/doc/org/webpki/json/JSONOb
>> jectReader.html> <http://webpki.org/papers/keyg
>> en2/doc/org/webpki/json/JSONObjectReader.html <
>> http://webpki.org/papers/keygen2/doc/org/webpki/json/JSONOb
>> jectReader.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
>>
>>
>>
>>
>>
>
>


-- 
Shane McCarron
Projects Manager, Spec-Ops