Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON

On 2014/07/11 05:40, Larry Masinter wrote:
>>> I also think it would be advisable to disallow duplicate names
>>> in application/merge-patch+json, but that requiring the other
>>> features of I-json is unnecessary.
>>
>> There is no need to re-argue what RFC 7159 says about this.
>
> I don't want to re-argue the decision. I'm just wondering
> "if i-json is useful, why isn't it useful for this?"

Thinking about it, it looks to me as if i-json and merge-patch are 
orthogonal, in the following sense:

If the original document and the patch data are i-json, then the result 
of applying the patch is guaranteed to be i-json.

I haven't checked this fully, but it seems to be the case at least for 
the lack of duplicate keys, and for restricted value ranges.

If that's the case, then that would provide a data point that these two 
specs are well designed, just not in the way Larry was looking for.

Regards,   Martin.

> i-json is being proposed as an IETF RFC describing a particularly
> interesting profile of JSON, giving it a special name, "I-JSON"
> based on the claim that this profile is more interesting
> than most other combinations of restrictions.
>
> But here's an application (application/ merge-patch+json)
> which -- as you point out -- doesn't mention I-JSON,
> even though some of the constraints of "which instances
> are meaningful to apply" would seem to be more easily
> expressed as a well-known profile of JSON. Just not
> I-JSON. The restriction on duplicate names is fine, but
> there's no need to restrict numbers to IEEE precision
> in the patch request.
>
> Mergepatch is one data point, are there other JSON
> application specs that COULD use i-json as a
> normative reference?
>
> If most cases of JSON application specifications that
> need 'clean JSON input required for results to be
> meaningful' profiles can't use I-JSON as a basis
> for 'clean', it casts doubts as to defining I-JSON as
> a category, rather than just a set of best practices.
>
>
> Larry
> --
> http://larry.masinter.net
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>