Re: [Json] [Technical Errata Reported] RFC8259 (7307)

[Tim Bray <[e-mail]>]

Yes, those are interesting ideas for improving JSON.  There are a lot of
such ideas, such as adding comments, distinguishing between integers and fp
numbers, and (my favorite) adding date/time literals.

If you'd like, you could try to start up a JSON 2.0 effort to add some of
these improvements to JSON. But I don't think that would have much chance
of success, I believe the community thinks “JSON is finalized” and it is
what it is. But it might be fun to try.

On Fri, Jan 13, 2023 at 10:20 AM Iurie Maxim <[e-mail]> wrote:

> Thank you very much Tim,
>
> Trough the ERATA I wanted to point that RFC8259 is not clear how to encode
> Null, and you indicated it quite clear as well:
>
> "RFC8259 doesn't help you very much.  For atomic types it provides
> strings, numbers, true, false, and null.  How you use these to represent
> your data is up to you."
>
> Wouldn't be then be better to clarify this in the RFC to allow programmers
> to clearly provide data in JSON format in a harmonized manner for <null>,
> <true> and <false> values?
>
> You also pointed that "In general it's reasonable to use the built-in
> null primitive (no quotes) to represent absent data, *but of course your
> code which is reading the JSON will have to understand this*"
>
> Wouldn't then a more clear RFC help all software developers to have the
> same understanding of Null and Boolean values and the API's that are
> starting to use more and more JSON instead of XML to be more interoperable
> instead of writing different code for different APIs even if all are
> providing data in JSON format and all data providers are correctly claiming
> that their JSON is correct according to RFC8259?
>
> If using {"Attribute1":null}, what about <true> and <false> taking into
> consideration:
>
> 3 <https://www.rfc-editor.org/rfc/rfc8259#section-3>.  Values
>
>    A JSON value MUST be an object, array, number, or string, or one of
>    the following three literal names:
>
>       false
>       null
>       true
>
>
> a) {"Attribute2":false} or
> b) {"Attribute2":"false"}
>
> Is RFC8250 or ECMA262 clarifying what is expected to be provided for
> Boolean values in a JSON ?
>
> Iurie
>
> On Friday, January 13, 2023 at 07:53:59 PM GMT+2, Tim Bray <
> [e-mail]> wrote:
>
>
> RFC8259 doesn't help you very much.  For atomic types it provides strings,
> numbers, true, false, and null.  How you use these to represent your data
> is up to you.
>
> It's almost certainly wrong to use the string "null" to represent an
> absent string field, because "null" is also a perfectly reasonable value.
>
> In general it's reasonable to use the built-in null primitive (no quotes)
> to represent absent data, but of course your code which is reading the JSON
> will have to understand this.
>
> JSON schema operates on a level above JSON and I'm not really an expert.
> I've looked at it but find it quite hard to understand.
>
> On Fri, Jan 13, 2023 at 9:47 AM Iurie Maxim <[e-mail]> wrote:
>
> Dear Carsten,
>
> Thank you very much for reply,
>
> Unfortunately, as I am not an expert neither in JSON, neither in writing
> an RFC, I wrote the errata as it is not clear for many of us how a web
> service should provide a response in JSON format if an attribute includes a
> <Null> value in the database and we have a debate in the company involving
> already too many people.
>
> Various implementations that are providing data trough an API, are
> encoding <Null> values from the database, in one of the following ways in
> JSON:
>
> 1) {"StringAttribute":null}, {"NumericAttribute":null}
> 2) {"StringAttribute":"null"}, {"NumericAttribute":null}
> 3) {"StringAttribute":"null"}, {"NumericAttribute":0} - this last is quite
> wrong I would say, or at least changing the original data where null is
> used for No data, but this seems to be correct according to ECMA 262.
>
> Can you please clarify which one of the above is correct?
>
> RFC 8259 is mentioning
>
> 3 <https://www.rfc-editor.org/rfc/rfc8259#section-3>.  Values
>
>    A JSON value MUST be an object, array, number, or string, or one of
>    the following three literal names:
>
>       false
>       null
>       true
>
>
> We saw all versions:
>
> a) {"Attribute1":false}, {"Attribute2":null}
> b) {"Attribute1":"false"}, {"Attribute2":null}
> c) {"Attribute1":false}, {"Attribute2":"null"}
> d) {"Attribute1":"false"}, {"Attribute2":"null"}
>
> Can you please clarify which one is correct?
>
> Below are some examples:
>
> 1) Any JSON validator that we use is validating all above encodings
> including for <null> and <false>.
>
> 2) This is how ESRI (www.esri.com) is encoding <Null> values from the
> database in a GeoJSON provided trough a Web Feature Service:
>
>
> "CountInitiallyInsertedRecords":633,"CountUnchangedRecords":null,"ListChangedAttributes":"null"
>
> [image: Inline image]
>
> 3) Here https://www.json.org/json-en.html <Null> it is written between
> quotation marks, as "null"
> [image: Inline image]
>
> 4) Here https://www.w3schools.com/js/js_json_datatypes.asp it is provided
> as example null without quotation marks
>
> [image: Inline image]
>
> 5) Here
> https://json-schema.org/understanding-json-schema/reference/null.html,
> although it is about the JSON schema, null is between quotation marks:
>
>  [image: Inline image]
>
> Really appreciate a clear response.
>
> The reason why I sent the ERATA is because in our company it is not clear
> which one is correct and neither RFC 8259 is providing a clear answer in
> conjunction with ECMA 262, neither we found official information which
> encoding are correct and which are incorrect.
>
> Best regards,
> Iurie MAxim
>
> On Friday, January 13, 2023 at 02:36:18 PM GMT+2, Carsten Bormann <
> [e-mail]> wrote:
>
>
> This errata report needs to be rejected.
>
> While it is easy to write documentation that is confusing, RFC 8259 is
> very clear here.
> A string, which always use ASCII typewriter quotation marks, is different
> from one of the special values »false«, »true«, or »null«, which do not use
> quotation marks.
> (Note that I used different quotation marks in this sentence, because the
> ASCII typewriter quotation marks I would normally use are exactly what is
> used in JSON to notate a string — hence much of the confusion.)
>
> In RFC 8949 [0] we went so far to invent our own convention for
> identifying JSON text in paragraphs (using angle brackets instead of the
> guillemets [1] I used above, which couldn’t be used in RFCs in 2020):
>
>   The notation borrows the JSON syntax for numbers (integer and
>   floating-point), True (>true<), False (>false<), Null (>null<), UTF-8
>   strings, arrays, and maps (maps are called objects in JSON; […]
>
> Anyway, there is no errata here in RFC 8259.
>
> Grüße, Carsten
>
>
> [0]: https://www.rfc-editor.org/rfc/rfc8949.html#section-8-4
> [1]: https://en.wikipedia.org/w/index.php?title=Guillemet
>
>
> > On 2023-01-13, at 12:06, RFC Errata System <[e-mail]>
> wrote:
> >
> > The following errata report has been submitted for RFC8259,
> > "The JavaScript Object Notation (JSON) Data Interchange Format".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7307
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Maxim Iurie <[e-mail]>
> >
> > Section: 3
> >
> > Original Text
> > -------------
> >      null  = %x6e.75.6c.6c      ; null
> >
> > Corrected Text
> > --------------
> >      null  = %x6e.75.6c.6c      ; null without quotation marks for
> numeric attributes and "null" for string attributes.
> >
> > Notes
> > -----
> > It is not clear how to encode null values in JSON.
> > Some are encoding all attributes as "null".
> > Some are encoding all attributes as null without quotation marks
> > Some are encoding string attributes as "null" and numeric attributes as
> null without quotation marks.
> > https://json.org is mentioning "null". ECMA 262  is mentioning "null"
> for string and +0F for numeric attributes. However providing zero for a
> number instead of null is incorrect and provides wrong results (in BI).
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC8259 (draft-ietf-jsonbis-rfc7159bis-04)
> > --------------------------------------
> > Title              : The JavaScript Object Notation (JSON) Data
> Interchange Format
> > Publication Date    : December 2017
> > Author(s)          : T. Bray, Ed.
> > Category            : INTERNET STANDARD
> > Source              : Javascript Object Notation Update
> > Area                : Applications and Real-Time
> > Stream              : IETF
> > Verifying Party    : IESG
>
> >
> > _______________________________________________
> > json mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/json
>
>
>