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

    "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:
> 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
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
> 