Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF

[Carsten Bormann <[e-mail]>]

> Suggested extra types:
> * "type": "intString" -- an integer exchanged in decimal notation as a JSON string, with no decimal point or exponent. (maybe only offer "int64String" instead, if it is only 64-bit values that typically use this format)
> * "type": "uintB64u" -- a (non-negative) integer (potentially huge, as often used in cryptography) exchanged as a JSON string holding the base64url-encoding (without padding) of an unsigned big-endian representation of the integer. (may need a comment about gracefully accepting leading 0 bytes).
> * "type": "bytesB64" -- a byte array exchanged as a JSON string holding its base64-encoding
> * “type": "bytesB64u" -- a byte array exchanged as a JSON string holding its base64url-encoding (without padding)

The list sounds good (I’m assuming byesB64 is base64 classic (Section 4 of RFC 4648) with padding); the names are a bit unwieldy — and give away the following observation:

This mixes application type (int, uint, bytes) with representation (there already is another representation in use for int and uint, and this adds two alternative representations for bytes).  Of course it is OK to mix the two (generate the product of possibilities), but it also can help to separate the two (and add a range constraint as a third, while uint8 does this so succinctly?).

Grüße, Carsten