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

Re: TJSON

From: Jacob Pratt <jhprattdev@gmail.com>
Date: Thu, 3 Nov 2016 14:42:21 -0400
Message-ID: <CAAFMpDr1Ux4eYRanuJLKYC6e9FOv4n4MeY4cv09pkn2tHQUxJA@mail.gmail.com>
To: Stefan Thomas <stefan@ripple.com>
Cc: Shane McCarron <shane@spec-ops.io>, Anders Rundgren <anders.rundgren.net@gmail.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Interledger Community Group <public-interledger@w3.org>
I'll second that. By allowing fields to be tagged, but not requiring it,
TJSON would still be compatible with JSON, while providing the same level
of specificity desired by the proposal. I think this also solves the issue
at hand of not knowing what type it is, as the issue only arises in cases
where it is encoded as a string, but is actually base64 or similar.

Jacob H. Pratt

On Thu, Nov 3, 2016 at 2:15 PM, Stefan Thomas <stefan@ripple.com> wrote:

> 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
>>
>
Received on Thursday, 3 November 2016 18:42:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 November 2016 18:42:57 UTC