Re: Questions about default

[Geraint (David)]

OK, I'm going to tackle this from the perspective of v4.  The "type" property can no longer contain objects in v4.  To achieve a similar effect, you have to use "oneOf" or "anyOf", depending on exactly what you want.

Using "oneOf" - there is no default.  All instances are valid under both inner schemas, which means that all instances are *not* valid under the parent schema.

{

    "oneOf": [

        {"default:" {"a": "a"}},

        {"default:" {"b": "b"}}

    ]

}

So the only way to fix this is to add constraints to the inner schemas, at which point - problem solved!  If an instance passes one, then one default applies.  If it passes the other, the other default applies.  If it passes both inner schemas, then it fails the parent schema, so it has no default at all.

On Thursday, 18 October 2012 15:50:50 UTC+1, Lionel Villad wrote:

The specifications (v3 and v4) are quite terse on describing the semantic of 'default'. In particular they don't address the following issues:

- The spec v4 says "This keyword can be used to substitute a default value for the production of a user interface.". First, it seems quite restrictive. Second, does that imply the input JSON is augmented with default values by the validator (similar to what XML schema validators do)?

- There are many cases where the use of default produces unpredictable output. For instance (using v3 syntax):

   { "type": [  { "default": { "a":"a" } }, { "default": { "b":"b" } } ] } 

Which of the 2 default values should be taken?

It seems to me 'default' is really underspecified and does not address edge cases.

[Geraint (David)]

With the second case (using "anyOf") - the default value from all matching schemas is used.  In your example, both schemas would apply, so the instance has multiple defaults.

So the essence of the problem is the same as using "allOf" (the equivalent of "extends" in v3):

{

    "default": 1,

    "allOf": [

        {"default": 2},

        {"default": 3}

    ]

}

The issue here is this:  If we explicitly defined *which* default should be used when there's more than one, we would need to define some kind of ordering on the applied schemas.  That's a can of worms I don't want to open.

So on balance, I would rather that we left the behaviour of "default" undefined in this case.  Perhaps some wording clarifying this in the specification, such as:

Since multiple schemas can describe an instance, instances may have multiple conflicting default values.  Which default value (if any) should be used in this case is not defined.

The specification does not explicitly state what agents can or cannot do with the default value.  Given that, I don't think that we particularly need to nail down what happens when there are multiple defaults.

[Eric G]

I have another, somewhat related question about default values, but I suspect the answer will be the same.  It seems you could have a default object specified, as well as default property values.

{

  properties: {

    one: { default: "1" }

  },

  default: { one: "2" }

}

Any thoughts on standard behavior in such cases, or should that be left undefined in the spec/ left to implementations to decide ?

On Friday, October 19, 2012 10:35:27 AM UTC-4, Geraint wrote:

...

[Geraint]

It's up to implementations.

What Jsonary would do is: when told "create some data following this schema", it would use {"one":"2"}, but if you then deleted the "one" property and re-added it, it would use an initial value of "1".

There are all sorts of fancy fallbacks and behaviour that could be specified - but I'd prefer to leave it up to implementations because I don't think that any given solution would be best for all cases, and implementations could get quite advanced.  I mean, if you have a default of any sort it would be ideal to do some kind of coercive validation to make sure it fits (and if multiple, choose the one with the least modifications, I guess), but I can sympathise with an implementation that just naively picks the first one or something.

[Eric G]

OK, thanks that's helpful to know what Jsonary does. Makes sense.