Re: [Json] JSON and int64s - any change in current best practice since I-JSON

[Tim Bray <[e-mail]>]

 Thanks for doing that. If there were a basis to have this discussion, I
would suggest shortening that list quite a bit.  But I really don’t see any
let’s-fix-JSON energy out there, much and all as it’d be satisfying. I
could easily be wrong but would need to see some evidence.

On Jan 22, 2024 at 3:54:22 PM, Joe Hildebrand <[e-mail]> wrote:

> I put together a quick requirements doc:
> https://github.com/hildjj/draft-hildebrand-eson-requirements
> This is just a starting point for discussion, any of it can be changed.
>
> —
> Joe Hildebrand
>
> On Jan 18, 2024, at 6:57 PM, Joe Hildebrand <[e-mail]> wrote:
>
>
> > On Jan 18, 2024, at 8:56 AM, Carsten Bormann <[e-mail]> wrote:
>
> >
>
> > Hi Joe,
>
> >
>
> > thanks for the list!
>
> > I’m CCing cbor@, as we are just finishing the extended diagnostic
> notation (EDN) document, and it is worth considering these points.
>
>
> Context for folks there: on the JSON list, there is a little bit of loose
> talk about a text-based format that would be a superset of JSON (perhaps?),
> would have defined numeric processing, including big integers, perhaps,
> maybe some of the features from JSON5 (https://json5.org/), might make
> commas optional (including trailing commas), etc.
>
>
> >> We would need to rework that grammar to make it suitable for
> interchange:
>
> >
>
> > [context: as a JSON extension]
>
>
> Yes.
>
>
> >> - Remove encoding indicators as mentioned
>
> >
>
> > Right.  When you say “remove”, you mean “do not include in JSON subset”?
>
> > (ABNF doesn’t have the “.feature” feature of CDDL…)
>
>
> I think by "JSON subset" you mean "subset of EDN used to define a text
> format".  That was confusing, because I was thinking "a text format that is
> a superset of JSON, perhaps influenced by EDN".  As such, "subset" and
> "superset" are referring to more or less the same thing.  I'm fine using
> your wording for the moment, with the understanding that the format we're
> talking about is not a subset of JSON, but a subset of EDN.
>
>
> I'm not tied to ABNF, but I don't think CDDL would work to describe the
> syntax of the notation itself.  It could be used to describe information
> encoded in the notation, though.
>
>
> >> - Reference IEEE754 for the 0x1.2p3 format, or remove it
>
> >
>
> > Good point.  Section 5.12.3 of IEEE Std 754-2019?
>
>
> I think so?  I can't find my copy of 754.
>
>
> >> - Remove embedded notation
>
> >
>
> > (I.e., not in JSON subset.)
>
>
> Yes.  This is only needed for expository text, not for interchange.
>
>
> >> - Remove ellipsis processing
>
> >
>
> > (I.e., not in JSON subset.)
>
>
> Yes.  This is only needed for expository text, not for interchange.
>
>
> >> - Discuss whether results should always be an array, as sequence is
> currently top-level
>
> >
>
> > Good question.  I gather the pickup of JSON sequences (RFC 7464) is not
> that great?  EDN is not entirely compatible with that as we don’t do the RS
> character, but do an explicit comma.
>
> > The JSON subset could simply use “item” as the entry point.
>
>
> Maybe I'm misunderstanding the ABNF in the EDN doc, but it looks like the
> top-level rule is `seq`, which is comma-separated.  I'm open to designing a
> streaming form of this notation at the same time, but that's a topic for
> discussion.
>
>
> >> - Discuss adding other JSON5 features
>
> >
>
> > Do you have some examples for what you would like to add?
>
> > What are we missing out for EDN?
>
>
> I like basically everything that JSON5 adds, except maybe escaping
> newlines; I think I'd prefer newlines to just be valid in strings without
> needing to be escaped.  I don't care about explicit `+` before numbers, but
> they don't bother me.  Reproduced here with comments:
>
>
> > Objects
>
> >    Object keys may be an ECMAScript 5.1 IdentifierName.
>
>
> Strong yes.  No need for quoting most keys in a world that has
> /\p{ID_Start}\p{ID_Continue}*/u
>
>
> >    Objects may have a single trailing comma.
>
>
> Strong yes.  I want to have the same coding standard in this format as I
> do for other languages.  I'm fine with all commas being optional for those
> that feel differently.
>
>
> > Arrays
>
> >    Arrays may have a single trailing comma.
>
>
> Yes.  See above.
>
>
> > Strings
>
> >    Strings may be single quoted.
>
>
> Same coding standard argument, plus there are times when I want to use "
> or ' without having to backslash-escape it.
>
>
> >    Strings may span multiple lines by escaping new line characters.
>
>
> This is for:
>
>
> ```json5
>
> "foo\
>
> bar"
>
> ```
>
>
> I'd prefer:
>
>
> ```eson
>
> "foo
>
> bar"
>
> ```
>
>
> >    Strings may include character escapes.
>
>
> This is for "\u{1F4A9}" in addition to "\uD83D\uDCA9", which is what you
> need to do in JSON.
>
>
> > Numbers
>
> >    Numbers may be hexadecimal.
>
>
> Fine.  Particularly nice for config files.  I don't think octal or binary
> is needed, but if someone else feels strongly, it's fine.
>
>
> >    Numbers may have a leading or trailing decimal point.
>
>
> Sure.  As long as we fix everything about numbers at least as well as
> I-JSON.
>
>
> >    Numbers may be IEEE 754 positive infinity, negative infinity, and NaN.
>
>
> Yes.
>
>
> >    Numbers may begin with an explicit plus sign.
>
>
> Shrug.
>
>
> > Comments
>
> >    Single and multi-line comments are allowed.
>
>
> Strong yes, and possibly the reason to do the work in the first place.
> Absolutely required for config files.
>
>
> > White Space
>
> >    Additional white space characters are allowed.
>
>
> Not important to me, but I don't speak any of the languages whose
> whitespace is now legal.  May as well include everything in Zs for
> future-proofing.
>
>
> >> We wouldn't get Tim's desired property of one character look-ahead.
>
> >
>
> > On constrained systems, you could always use CBOR…
>
>
> Tim can make his own argument here.  I think I'm on record as believing
> that CBOR is a good thing.
>
>
> >> Other than that, it's as good a place to start as anywhere else.
>
> >
>
> > Indeed.
>
> > I could imagine we finish the EDN-literal document for its CBOR target
> audience, and then write another document about the JSON subset (which
> would be less of a delta and more of a free-standing specification that is
> just anchored in the full version for CBOR).
>
>
> I think "inspired by" is as far as I'd commit to at the moment, until we
> have some agreement on requirements.
>
>
> > I just noticed that we do have a required comma between items in arrays
> and sequences.  I just confused this with CDDL (which I’m prone to do),
> where that comma is not required.  Leaving off the comma conflicts with
> implicit string concatenation (which is one way to address the 2D string
> problem).  So maybe there is a bit more work to do...
>
>
> I don't think this format needs string concat.
>
>
> --
>
> Joe Hildebrand
>
>
>
>