What's a concrete example of functionality this provides?

My interpretation of "default" is a suitable initial value for the instance when it's created; so at the very least, I think {} may be a preferable value over true. See also #867

This is to restore consistency to the metaschemas. In most other places, a default keyword is provided to indicate the intended behaviour when the keyword is absent from a subschema -- this just fills in the places where the default was missing. true is used in other places where the current position is a subschema (which can be a boolean or an object).

Is this good to include in draft2020-xx?

rebased

Hm.. I didn't see this when I did #1057. May have duplication.

Given that we don't provide defaults in the same schema object which uses a ref or dynamic ref, we should remove that found in the applicator vocab schema on line 17, right?

And for propertyNames?

I think I'll merge this as best I can, then remove the defaults where $dynamicRef is used.

Can this be rebased one more time please?

rebased!

In the end, this is the diff I get against master. is this what we want?

diff --git a/meta/applicator.json b/meta/applicator.json
index ff2cfc2..8652779 100644
--- a/meta/applicator.json
+++ b/meta/applicator.json
@@ -13,8 +13,7 @@
 "items": { "$dynamicRef": "#meta" },
 "contains": { "$dynamicRef": "#meta" },
 "additionalProperties": {
- "$dynamicRef": "#meta",
- "default": {}
+ "$dynamicRef": "#meta"
 },
 "properties": {
 "type": "object",
@@ -33,8 +32,7 @@
 "default": {}
 },
 "propertyNames": { 
- "$dynamicRef": "#meta",
- "default": {}
+ "$dynamicRef": "#meta"
 },
 "if": { "$dynamicRef": "#meta" },
 "then": { "$dynamicRef": "#meta" },
diff --git a/meta/validation.json b/meta/validation.json
index 606b87b..1432ad8 100644
--- a/meta/validation.json
+++ b/meta/validation.json
@@ -65,7 +65,8 @@
 "type": "object",
 "additionalProperties": {
 "$ref": "#/$defs/stringArray"
- }
+ },
+ "default": {}
 }
 },
 "$defs": {

Given that we have been using the default keyword wrong anyway (missing keywords cannot produce annotations), maybe something like this is more correct: https://gist.github.com/karenetheridge/1239b063611b937c38713f6ac6a6eaa6

@karenetheridge

missing keywords cannot produce annotations

That has never occurred to me. We would only know the default value if the value exists, but the only reason to care about the default value is if the value doesn't exist.

 "default": {
 "items": true,
 "contains": true,
 "additionalProperties": true,
 "properties": {},
 "patternProperties": {},
 "dependentSchemas": {},
 "propertyNames": true,
 "if": true,
 "then": true,
 "else": true,
 "not": false
 }

If an entire schema is missing, I would expect this default to apply. However, if the schema does exist with some of these values missing, I wouldn't expect this default to those values. The default would be applied all or nothing. So, I don't think this makes sense either.

It seems default is completely useless, even as an annotation.

If an entire schema is missing, I would expect this default to apply. However, if the schema does exist with some of these values missing, I wouldn't expect this default to those values. The default would be applied all or nothing. So, I don't think this makes sense either.

Well, the user can do whatever he likes with the annotations he gets back -- it doesn't have to be all or nothing. In some of my code (that is, the caller of the json schema evaluator - not the evaluator itself!), I retrieve that default annotation and add its values into the data instance for every property that is missing.

Here's another approach we might take with where we use default in meta-schemas.

If a keyword isn't present it has no effect. There's no reason to declare a default value that also has no effect. The only reason to have a default value is for keywords that depend on other keywords for their results. In order to process additionalProperties, we need to know the value of properties and patternProperties. Therefore, properties and patternProperties should have a default value. Things like allOf/anyOf/oneOf/not don't need defaults because nothing depends on their presence.

if would be a weird one tho. I'd have to look it up, but I'm pretty sure then and else don't apply if if is not present. So, when you're looking at then, if's default is false. If you're looking a else, if's default true.

I think we can leave out properties and patternProperties too -- as the spec says what to do if those keywords are missing (no keyword -> no annotation -> nothing to consume when considering the result of additionalProperties, unevaluatedProperties).

We can leave out if/then/else and not as well -- no keyword -> nothing to do -> no false value injected into the result.

The only outliers really are "minContains", which defaults to 1 when absent, and the meta-data keywords which default to false. We should be able to drop all the rest.

edit: and '$schema', which defaults to the main metaschema $id.

I think properties and patternProperties might be nice to have as a way of documenting what the spec says, but I agree they aren't necessary.

I agree if/then/else don't need defaults and minContains should have one.

Others to consider are

1. addtionalProperties - true - depended on by unevaluatedProperties
2. items - true - depended on by unevaluatedItems
3. prefixItem - [] - depended on by items

I think it would be a nice-to-have to include these defaults, but not necessary.

I pushed another commit for consideration, which would be squashed with the other two if acceptable.

@karenetheridge

the user can do whatever he likes with the annotations he gets back -- it doesn't have to be all or nothing

I agree that default can be used however we want, but I'm not a fan of this approach. It feels awkward and wrong to me. I'd rather use it the way we have been.

Not a hard objection, just my preference. I won't argue if others like it.

It seems default is completely useless, even as an annotation.

This is close to my conclusion too, see #867

I agree with @jdesrosiers's idea of only including defaults for keywords that have other keywords being dependent upon them.

Going forward, maybe we need to declare the default values of keywords in the context where they're depended upon. For example, the section for contains would define a default for minContains should it be absent, opposed to as it is now where the section for minContains declares its own default. This also has two side effects:

• a keyword (or subschema) can have different defaults based on the context in which it's used,
• custom keywords can be written (in new vocabs) that utilize keywords with different defaults.

Note that this doesn't give the default keyword any more purpose than for humans.

In agreement with changes requested by @gregsdennis and @jdesrosiers, including those in
#1006 (comment)

addtionalProperties - true - depended on by unevaluatedProperties
items - true - depended on by unevaluatedItems
prefixItem - [] - depended on by items

For example, the section for contains would define a default for minContains should it be absent

I don't see how that can be done with current syntax, because anything we put here would be defined at the .../contains/ position, not .../.

I have pushed one more commit for consideration.

I don't see how that can be done with current syntax...

Yeah, it can't. Was just thinking out loud.

So the net result of this PR is dependencies gets a default? Was that the intent?

Do we want to handle defaults for prefixItem and items in a separate PR?

The net result is that defaults have been removed for all subschemas that recursively-reference #meta (e.g. additionalProperties, propertyNames), and dependencies gets a default. borrrring!

prefixItems already has a default, via the schemaArray definition, and items is another #meta reference.

I can squash with a better commit message if we're good with this (or let Relequestual do it).