Re: TJSON

My take on TJSON is that it definitely solves a real problem that I've
personally run into. When looking at a JSON document, you don't know
whether a given value is a string or base64 for instance. JSON-LD is a
possible option, but comes with a lot of other features that you don't
always need.

My only feedback would be that it would like to see more of an effort to
make TJSON a superset of JSON as opposed to requiring every field to be
tagged with a type.

If I have:

{
  "count": 5,
  "key": "AANFJzysAFsbashj==",
  "message": "Hello!"
}

Why do I have to add a ton of tags? Why not just:

{
  "count": 5,
  "key:b64":  "AANFJzysAFsbashj==",
  "message": "Hello!"
}

I.e. tag the fields where your default guess of the type would be wrong and
leave the rest of the fields as-is.

On Thu, Nov 3, 2016 at 8:46 AM Shane McCarron <shane@spec-ops.io> wrote:

> 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/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
>
>
>
>
>
>
>
>
>
> --
> Shane McCarron
> Projects Manager, Spec-Ops
>