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

[Larry Masinter <[e-mail]>]

> > 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?"

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