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

Hi,

I thought I might also add that I use <https://serde.rs> for most of these
tasks these days.

Sometimes, I do use what they call "field attributes":
https://serde.rs/field-attrs.html

You need these so your deserialized structs pass all of the common linter
tests.

I don't think this way of doing things would extend to a document format
like HTML or XML, but you can certainly cover JSON, YAML, and CBOR with it.
So, I now rarely interact with a parser for those kinds of things, and thus
I'm agnostic on any wire format particulars.

thanks,
Rob

On Thu, Jan 18, 2024 at 5:57 AM Carsten Bormann <cabo@tzi.org> 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.
>
> > We would need to rework that grammar to make it suitable for interchange:
>
> [context: as a JSON extension]
>
> > - 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…)
>
> > - Reference IEEE754 for the 0x1.2p3 format, or remove it
>
> Good point.  Section 5.12.3 of IEEE Std 754-2019?
>
> > - Remove embedded notation
>
> (I.e., not in JSON subset.)
>
> > - Remove ellipsis processing
>
> (I.e., not in JSON subset.)
>
> > - 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.
>
> > - Discuss adding other JSON5 features
>
> Do you have some examples for what you would like to add?
> What are we missing out for EDN?
>
> > We wouldn't get Tim's desired property of one character look-ahead.
>
> On constrained systems, you could always use CBOR…
>
> > 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 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...
>
> Grüße, Carsten
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>