pre-populate default values from schema (command-line option)

[rssh22]

Hi,

I think it would be very useful for validating json documents against schemas a command-line option that would allow to pre-populate defaults into the document like python-jsonshema docs suggest here:

https://python-jsonschema.readthedocs.io/en/stable/faq/#why-doesn-t-my-schema-s-default-property-set-the-default-on-my-instance

It would make easy to validate documents like it is suggested just from the command-line tool

[sirosen]

I'm perfectly happy to add this as a feature. As the doc you cite shows, it's pretty easy.

I think there are hidden dangers here, but as long as it's gated behind a flag, I don't have a huge problem exposing people to those dangers. Detail below.

---

Bad case 1: default works, but meaning is unclear

If you have a schema like so:

{
  "type": "object",
  "properties": {
    "foo": {
      "default": "bar",
      "type": "string"
    }
  },
  "required": ["foo"]
}

then a file containing {} is invalid. If we fill defaults, it would read as valid even though the file isn't -- the file + default-filling behavior produces a valid document.

The duality could lead to confusion.

Bad case 2: invalid defaults

Consider this schema:

{
  "type": "object",
  "properties": {
    "foo": {
      "default": 42,
      "type": "string"
    }
  }
}

Applied to {}, default-filling produces an invalid document. But the document {} is valid.

Because the schema specifies something odd, a valid document can't pass validation with this behavior.

---

As I said, I'm happy to add this, as it's "use at your own risk". But I felt it was only responsible to point out some of the odd cases (which you might think of as corner cases).

[rssh22]

Yeah, that's an interesting discussion. I agree it could be some use cases where is unclear the expected behaviour.

In my opinion (which is just my opinion right now) I consider that de case 2 should be considered as an application bug. The developer has set as default value something that can't be a valid value. However, I understand that is context dependant.

In case 1, I can argue that: A purpose of declaring default values is to free the developer of setting every required value. Making it simple. So having a {} document could be perfectly valid for the application because it will know the default values.

Despite the unclear expected behaviour, I really think it could be a good feature.

Thanks for taking it into account

[rssh22]

Just a suggestion that may help to clarify case 2 scenario. If the property is not required, then the default value will not be populated.

[sirosen]

I've just finished adding this and it will be included in the next release.
For now, the documentation is minimal, and merely notes that there are ambiguous schemas in which the meaning of "default" is considered undefined.

Just a suggestion that may help to clarify case 2 scenario. If the property is not required, then the default value will not be populated.

I understand that you're trying to come up with ways around these issues, and maybe in some cases it's possible. However, I primarily aimed to share that I don't think this is a solvable problem in the general case.

For a few more examples, if an "allOf" schema specifies multiple conflicting values for "default" on the same field, what does that mean? If the default values are objects, not simple strings, should those objects be merged?
And keep in mind that all of these things can be nested. "allOf" can be wrapped in "oneOf". Conflicting "required"lists can exist across parts of a"oneOf", and may be wrapped in a container which provides a different "required"` list.

As long as the docs clarify that there are known-undefined behaviors in such special cases, I'm okay with --fill-defaults having the "intuitive" and eager behavior of filling in any "default" it sees. This works in simple cases and is what I merged a few minutes ago.