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

From: Ulysse Carion <[email-masked]>
Date: Wed, 28 Aug 2019 12:57:14 -0700

Hi folks,

I want to continue to thank y'all for the attention to detail provided
in past iterations of JSL. The new I-D is published here:

https://tools.ietf.org/html/draft-ucarion-jddf-00

The name of JSON Schema Language has been changed to JSON Data
Definition Format ("JDDF"). This is to avoid confusion with "JSON
Schema". The JSON Schema folks asked that I changed the name, and I
don't mind doing so. Sorry for the confusion.

The most important changes are to the introduction. I've clarified
what JDDF's niche is (code generation), as well as my position on what
seems to be ideal for a schema language optimized for code generation:

https://tools.ietf.org/html/draft-ucarion-jddf-00#section-1

I fear we may be at loggerheads on the question of {"type":"int53"}. I
continue to prefer for its omission from the spec. James, Carsten --
might we ultimately have to agree to disagree on this question? It
seems easier to later on add int53 than to later remove it.

Best,
Ulysse

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Aug 2019 07:42:11 +0200

"The principle of common patterns in JSON is why JDDF does not support
     64-bit integers, as these are usually transmitted over JSON in a non-
     interoperable (i.e., ignoring the recommendations in Section 2.2 of
     [RFC7493]) or mutually inconsistent (e.g., using hexadecimal versus
     base64) ways"

I understand the motivation but since the world outside of the JSON WG
have proved to be fairly capable dealing with these issues, I don't agree
with this design principle.

IMO this is rather simple problem; make format/representation a separate
item, unrelated to the number type itself. That some combinations may be
ridiculous or very unlikely to be found in the wild shouldn't be a
problem for a properly designed schema processor.

There could though be reasonable (whatever that is...) defaults.

I may have read the draft in too much haste but I didn't see any support
for binary data.  Yeah, supporting that would also put JDDF on a more
difficult path and my stock of silver bullets is essentially empty :-)

Anders

On 2019-08-28 21:57, Ulysse Carion wrote:
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: "Manger, James" <[email-masked]>
Date: Thu, 29 Aug 2019 07:41:43 +0000

> ...
> I fear we may be at loggerheads on the question of {"type":"int53"}.

JDDF offers "type":"uint8" but very common languages, such as Java, don't have an unsigned 8-bit type. So code generation might use a short (16-bit signed integer) to handle the [0, 255] range. That seems to put the code in a very similar situation to using a long when the JDDF says "int54". In both cases the native type can hold values that the schema doesn't allow, requiring extra parse/stringify functions if you really want to enforce the schema's rules.

>> I didn't see any support for binary data

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)

--
James Manger

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Aug 2019 10:33:28 +0200

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Aug 2019 10:43:58 +0200

On Aug 29, 2019, at 10:33, Carsten Bormann <[email-masked]> wrote:
> representation

… and adding something closer to a proposal to my observation:

intString is an int[unlimited?  64?] in decimal.
(Note that the below are all strings on the JSON side, too; nothing is special requiring calling out the use of Strings, but it should be said that they are decimal(*)).

uintB64u is an uint_unlimited in (msb-first bytes and then) b64u (Section 5/no padding).

bytesB64 is a byte string in b64c (Section 4/padding).
bytesB64u is a byte string in b64u.

Note that there is no “default” representation of byte string in JSON, so this always needs a representation (possibly the JDDF defines a default, which would be b64u).

Grüße, Carsten

(*) should have a position on leading zeros…

---

From: John Cowan <[email-masked]>
Date: Thu, 29 Aug 2019 08:38:15 -0400

Proposed schema types for JDDF purposes:

Fixed-length strings and bounded strings: both useful in contexts where
dynamic memory allocation is not allowed for performance, security, or
low-memory reasons.

Fixed-length and bounded arrays: same reasoning.

Tuples:  These are fixed-length JSON arrays where each element potentially
has its own type.  They can be translated into languages that don't have
them natively (as Python does) using a struct/class with synthetic field
names like element0, element1, ... or just _0, _1, ....