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

[Tim Bray <[e-mail]>]

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