Re: [Json] I-JSON Topic #2: Top-Level

[Nico Williams <[e-mail]>]

On May 28, 2014 3:57 PM, "Matthew Morley" <[e-mail]> wrote:
>> Does anyone have additional arguments to make for or against what
>> constitutes an I-JSON top-level?

[...]

> With the top-level restriction in place, but without a standard structure:
>   - non-structured data must be encapsulated: {"result":42}
>   - structured data would be ambiguous: {} -or-  {"result":{}}
>
> If you are in a system that uses function composition, it means you need
to bake this into your expected types/categories, or have a design that
handles and hides the encapsulation/decapsulation steps from the
composition reasoning portion. I don't have (or plan) such a system, so
this is outside my expertise, but imagine this being a limitation for those
that might have/want such a system. (?)

Thanks for capturing this issue so clearly.  Yes, superfluous encapsulation
is obnoxious, particularly in systems with computable units not all of
which produce the blessed output types.

Remind me, what do we gain from this?  Interop with old libraries that
probably don't conform to I-JSON anyways and which stand a good chance of
being fixed soon enough that this top-level restriction ends up buying us
nothing a year hence.  Please re-think this!

Nico
--