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

On Fri, Apr 14, 2023, at 11:43, Mark Nottingham 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
> }
> ~~~

Just to clarify, "a" and "b" are sf-decimal here, which means that the JSON type system is doing some amount of lifting in terms of identifying type.  If "a" were to be a display string, we might need:

{ "@type": "string", "@val": "foo",
  "a": { "@type": "display string", "@val": "metal ümlaüts" },
  "b": 2 }

Is that right Mark?

That would imply a reduced form that is something like this for sf-list of sf-decimal: [ 1, 2, 3, 4 ].  That implies a question though: would sf-integer need to use the "@type" form as JSON numbers aren't readily identifiable as integers?  Would JSON types each have a default interpretation?  JSON types are unambiguous only in some cases.  sf-list and sf-boolean seem fine, but maybe less so for others, and we are overloading dictionaries here too.

Received on Friday, 14 April 2023 03:37:04 UTC