Re: [dispatch] Request for feedback on draft-thomy-json-ntv-01

[Philippe THOMY <[e-mail]>]

On Fri, Sep 15, 2023 at 8:09 PM Dale R. Worley <[e-mail]> wrote:

> Philippe THOMY <[e-mail]> writes:
> >  Two interpretations are possible:
> > - JSON-NTV is not used enough in the IETF, so it will not be able to
> evolve
> > into RFC
> > - JSON-NTV is not used enough in the IETF, it must therefore be used more
> > in the IETF to evolve into RFC
> > (I prefer the second interpretation !!)
>
> My meaning is a somewhat vague, but could be phrased "Why does the IETF
> care?"  Usually the answer to that is that various network operations
> involve the concept in question, or would be improved by using the
> concept in question.
>

You are right, the question is completely legitimate.

Here are some partial answers:

*General view:*
The semantic level of shared JSON or CSV data remains low. It is often
limited to the type of data defined in these exchange formats (strings for
CSV formats; numbers, strings, arrays and objects for JSON formats).
The reuse of data cannot therefore be automated without an external 'data
schema' (e.g. if I have data [4.21, 41.234, 4.31, 41.5] I do not know what
this array represents. In the JSON-NTV format, the type is integrated and
the data will be {':box': [4.21, 41.234, 4.31, 41.5]}. 'box' is a standard
type defined in GeoJSON and I can automatically transform it into a
'polygon' which can be visualized on a map).
These automation (and quality) gains are found in several areas: IoT
interface (for those who use JSON), database interface, BI/Dataviz
interface, open-data, data analytics

*Example of tabular data (application that I know best): *
The majority of open-data sharing is carried out with the CSV format
(RFC4180 - 2005). This format is obsolete and continues to exist (with
non-standard extensions) only because there is no alternative format.
The JSON-NTV format for tabular data (not yet described in an ID) is an
optimized format (size) compared to the CSV format and explicitly addresses
the question of column typing (and automation of reuse of tabular data ).
This also makes it possible to have an identical file format and API format
(facilitates the accessibility of open-data data).
Furthermore, the module implemented with pandas shows that this makes it
possible to have a reversible JSON format (lossless round trip) for all
data structures supported by pandas (does not exist today).


*Why IETF?*
The IETF has managed the CSV format and manages the JSON format and its
extensions (e.g. JSON-patch, JSON-pointer, JSON-path, GeoJSON, CBOR).
Naively, it therefore seems 'logical' to me that this extension is
supported by the IETF.


> > - does the [JSON-NTV] notation refer to a possible WG?
>
> Actually, "[JSON-NTV]" is the reference tag the I-D uses for a document.
>
>
Thanks, that’s clear.

Dale
>