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

On Fri, Apr 14, 2023 at 11:43:30AM +1000, Mark Nottingham wrote:
> *editor hat*
> Just to make sure people saw it: <>
> 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.

I don't think the problem is weirdness due to HTTP, but that the
data model does not seem compatible with JSON.

I think the biggest data model issue is that SF parameters and dicts
are both positional and keyed. JSON only has positional but not keyed
(arrays) and keyed but not positional (objects).

Then there is representing things like inner list in dict, where each
value in dict may have parameters, and the list as whole can have
parameters. And each value might need explicit type.


Received on Friday, 14 April 2023 08:09:35 UTC