Re: Structure Fields bis: JSON mapping (#2504)

What sorts of places were you imagining using this? Since the data model
doesn't align with JSON, this (and I suspect any) mapping is quite verbose.
JSON suggests interchange (it's right there in RFC 8259's abstract!), but I
can't see using it in any JSON-based protocol. Just embedding the textual
HTTP representation in a JSON string would be more efficient.

If it's not for interchange, and just for some kind of API, I can't imagine
anyone wanting to embed "@type": "string" and "@val" into an API surface.
Rather, given the incompatible data models, I think APIs would need to use
the host language in non-JSON ways to better capture SF's data model. In
that case, a verbose JSON mapping doesn't help. (Had SF's data model been
more JSON-compatible, it'd be another story but, for better or worse,
that's not where we are.)

Going through the exercise of designing a clean and simple APIs seems
prudent (and perhaps, in an alternate design path, could have informed the
data model!), but it's not clear to me how this does that.

David

On Thu, Apr 13, 2023 at 9:44 PM Mark Nottingham <mnot@mnot.net> wrote:

> *editor hat*
>
> Just to make sure people saw it: <
> https://github.com/httpwg/http-extensions/issues/2504>
>
> SF's data structures are somewhat weird, because of how HTTP fields work.
> It might be useful to suggest (not mandate) a mapping to JSON data
> structures, e.g., in an appendix.
> We talked about what the right mapping should be in the 2022 HTTP
> Workshop, and this was what we ended up with on the whiteboard:
>
> ~~~
> {
>    "@type": "string",
>    "@val": "foo",
>    "a": 1,
>    "b": 2
> }
> ~~~
>
> Note that @type could default to string.
>
> Thoughts? Is this worth putting into an appendix? Personally, I think it
> could help drive convergence in APIs for SF -- *if* we're reasonably
> certain we have the right approach.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>