Re: TJSON

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