[Json] JSON Schema Language: extensibility and unspecified properties

[Ulysse Carion <[e-mail]>]

Hi folks,

Thanks again for all the wonderful suggestions for JSON Schema
Language. I've just published a new draft incorporating suggestions
from the last update. You can read it here:

https://tools.ietf.org/html/draft-ucarion-json-schema-language-02

I would like advice on the two following changes I've made to the spec.

First, I added explicit discussion of how JSL can be extended. The
language is at the end of section 2, but I'll reproduce it here:

> This document does not describe any extension mechanisms for JSL schema
> validation. However, schemas (through the `non-keyword` CDDL rule in this
> section) are defined to allow members whose names are not equal to any of the
> specially-defined keywords (i.e. `definitions`, `elements`, etc.) described in
> this section. Call these members "non-keyword members".
>
> Users MAY add additional, non-keyword members to JSL schemas to convey
> information that is not pertinent to validation. For example, such non-keyword
> members could provide hints to code generators, or trigger some special behavior
> for a library that generates user interfaces from schemas.
>
> Users SHOULD NOT expect non-keyword members to be understood by other parties.
> As a result, if consistent validation with other parties is a requirement, users
> SHOULD NOT use non-keyword members to affect how schema validation, as described
> in {{semantics}}, works.

Basically, my stance is: you can add custom stuff to schemas, but you
can't change validation. I expect that people will change validation
anyway, but they're not going to expect portability. I don't feel that
adding some sort of registry of keywords / forms is valuable yet.
Perhaps something like that can be in whatever replaces JSL?

How do folks feel about this? Does anyone have suggestions on better
ways I can approach extensibility, or how I should phrase this
language?

The other thing I want advice on is "strict" mode, called "strict
instance semantics" in the spec. Basically, strict instance semantics
about whether it's ok to send "extra"/"unknown"/"unspecified"
properties in an object.

Right now, validation behavior is specified as a single, top-level
"strict": true/false (default is "true") property. You can't mix and
match strict and non-strict. But Carsten off-list noted that might be
a bit "blunt". Do others agree?

The context for my decision is that two of major typed languages used
in industry, Java and Golang, don't typically support mixing and
matching. Go just as a blunt DisallowUnknownFields:

https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields

And Java's Jackson has a FAIL_ON_UNKNOWN_PROPERTIES:

http://fasterxml.github.io/jackson-databind/javadoc/2.9/com/fasterxml/jackson/databind/DeserializationFeature.html#FAIL_ON_UNKNOWN_PROPERTIES

Both are all or nothing.

Also, there is the question of whether "strict" is a good name for
this property in schemas. Is there a better name for it? "strict" can
be understood in many ways. Open to ideas here as well.

Other changes:

- Removed int64/uint64 (and removed discussion related to I-JSON)
- Clarified that 1.0e1 is an integer

Finally, I've moved JSL to a desired status of "Informative", and I'll
be going through the independent stream once the discussion here
appears to have settled.

Thanks again for all the help,
Ulysse