Re: [Json] JSON Schema Language: extensibility and unspecified properties

[Ulysse Carion <[e-mail]>]

Also: from off-list discussion, and from talking with folks in
industry about their experiences taking legacy systems and
retrofitting schemas onto them, I think the spec's current approach to
"unexpected/unspecified/additional" properties is inadequate.

In the current draft, whether to tolerate properties not mentioned in
a schema is a global option on the schema. This is not good enough,
because oftentimes folks only progressively lock down parts of their
schema -- some parts are better documented and can be locked down, but
other parts may be inscrutable or just too risky to lock down.

So I'm thinking, in the next draft, for schemas -- be they root
schemas or sub-schemas -- to be able to specify whether they'll allow
properties outside those mentioned in properties/optionalProperties.
Also, since "strict" is super vague, I'll rename it
"additionalProperties". It'll still take true/false, but now the
default is "false" and the value's meaning is flipped.

On Sat, Aug 17, 2019 at 6:34 PM Ulysse Carion <[e-mail]> wrote:
>
> Carsten, I think you are bringing up an important point. I should
> clarify what is and isn't a type in the spec, and what the principle
> is for deciding that.
>
> I'd like to add a brief discussion of that reasoning in the
> introduction of the next draft. Does this principle make sense to
> folks here?
>
> "Only include in the spec things which are (1) commonly (and portably)
> used in the JSON ecosystem, and (2) which have a clear mapping to
> programming languages in widespread use today."
>
> By that standard, int64/uint64 fails (1), as it's unportable (i.e.,
> not I-JSON) or implemented in a bunch mutually incompatible methods.
> int53 fails (2) because no mainstream language I know of has support
> for integers strictly up to 2^53.
>
> I disagree with you about uint8. I think we agree it satisfies (1); it
> seems we disagree on whether it passes (2)? Perhaps you were thinking
> of Java's strictly-signed "byte". If so: by convention, Java folks
> ignore the signed-ness of byte when uint8 is needed. This is perhaps a
> bit sketchy (since you can so easily mix and match signed and unsigned
> 8-bit numbers), but it has gotten the job done in many applications.
> So the spec's uint8 and int8 both correspond to Java's byte, in my
> view.
>
> On the principle above, I think I should remove {"type": "number"}
> from the spec. It's unclear what "number" means. Does it mean
> BigDecimal? If so, it's not portable and so fails (1). Does it mean
> float64? Then just use {"type": "float64"} instead.
>
> On Mon, Aug 12, 2019 at 10:31 PM Carsten Bormann <[e-mail]> wrote:
> >
> > On Aug 13, 2019, at 07:03, Ulysse Carion <[e-mail]> wrote:
> > >
> > >> However, it seems bizarre to support int8, int16, and int32, but not JSON’s generic interoperable integers.
> > >
> > > Supposing we add int53 to JSL, do you picture code generators
> > > producing int64_t/long for {"type": "int53" }? Does that mean that,
> > > before serializing an int64_t to something marked as int53 in JSL, the
> > > application must first do an extra bounds check? Today, it's fairly
> > > easy to generate code from JSL where serializing is an infallible
> > > affair. But with int53, that property would be lost, because most type
> > > systems cannot express int53.
> >
> > Many type systems don’t have a uint8, either.
> >
> > > I'm inclined to think this is something better handled by extensions.
> > > Perhaps someone can define a "intt53" property to do something like:
> > >
> > > { "type": "number", "int53": true }
> > >
> > > The person writing the extension would document that the "int53"
> > > property indicates whether a number is meant to represent a number in
> > > the I-JSON range. Applications which don't understand this keyword
> > > will still do something reasonable -- validate for some sort of
> > > number, and code generate a "double" -- but applications which care
> > > about this can handle this case specially. It also signals an intent
> > > about how the number will be used.
> >
> > Again, the same is true for uint8.
> >
> > (This opens the whole “types vs. subtypes” discussion.)
> >
> > > I expect this sort of approach is how JSL may need to handle
> > > big-number encoding schemes. There are so many different ways approach
> > > that problem, and I think JSL is most useful if it establishes an
> > > uncontroversial foundation, and then lets additional, out-of-spec
> > > keywords tighten the schema further in a way which most folks don't
> > > care about, and hence don't want to have to implement.
> > >
> > > Does that seem like a reasonable approach?
> > >
> > >> Actually, that’s something JSON can’t deal with.
> > >
> > > By this you mean that JSON prescribes "all numbers are doubles", and
> > > so integers aren't really a good thing to try to foist onto JSON's
> > > syntax?
> >
> > Integer is a mathematical concept.  JSON does not have a problem with that.
> >
> > The problem comes in when applications arbitrarily restrict the syntax.
> >
> > Not allowing a fractional or exponent part is akin to requiring two spaces of indentation before or a newline after a number.
> >
> > It gets worse when syntax variations are assigned different application semantics.
> > (E.g., I’m aware of at least one “JSON-based” syntax where a string that starts with “\u0073” has semantics different from a string that starts with “s”.)
> >
> > You can’t do that to a format like JSON and still be part of the JSON ecosystem, because generic JSON decoders discard these syntax features, and generic JSON encoders generally can’t produce them.
> >
> > >> MS-Excel has repeatedly taught me that my university phone number is 2.1863921e7, but people still manage to call me :-)
> > >
> > > Could you expand what you mean here? I realize no joke is funny enough
> > > to survive explanation, but I’m afraid I'm perhaps missing your point.
> >
> > Well, my phone number is 21863921, but some spreadsheets consider this a large number and turn it into an NR3 number…
> >
> > Grüße, Carsten
> >