Default values of schema attributes

[David]

Hello,

After reading the spec I understand that the default values are:
required: false
additionalProperties: {} # "The default value is an empty schema
which allows any value for additional properties."
additionalItems: false if items == schema, else {}.

1) I don't agree with these defaults as to me personally, a schema is
a description of an agreed, locked-down protocol. With these defaults
there's a lot of wiggle room, i.e. clients can add extra properties by
default and they don't have to provide data in the schema by default,
and can still pass schema validation. My initial thinking is that
those defaults don't represent the majority of use cases.

2) This wouldn't really be a big deal if there was some way of
changing these defaults in the schema. Then I'd happily just say
"@defaults":{"required":true}" and I'd save lots of lines of schema
code and verbosity.
Correct me if I'm wrong but I didn't see a way of doing that in v3 of
the schema spec. Instead I have to specify required: true and
additionalProperties: false all over the place adding about 20% extra
size to the schema.

I don't know how to get around this. I just know that I really don't
want to have to copy and paste the same lines on schema as a
workaround. I assume others will find themselves in the same situation
too.

So, thoughts?

Cheers
David

[Xample]

1. At first the required is now placed into an Object description as an array in the draft4. (which is much better)

2. There is no additional items possible if the item is something, the additional item is only applicable when an array of items is provided and that we run out of schemas compared to the number of items to validate. In some way you can consider the additionalItems to be {} even if the items is a schema.

3. My thoughts are that it should have been added an "extends" which would override keys (in opposition to the current extends which currently acts more likely like an include)

[David]

Hey Xample, thanks for the info. I google'd draft4 of the spec and
found some commentary on the proposed changes. Where is that
discussion being had do you know? Here? Who's making proposals and
deciding what proposals get accepted?

Anyways, it seems v4 will have us do this: "required":
["a","b","c","d","e"]
That's quite repetitive, and as we all know duplication usually is a
shortcut to problems.
I think having it as an attribute like in v3 makes sense, provided
there is some way to either change defaults or have it inherited
within properties trees so that it cascades down to children that then
have the right to override it.

Re: additionalItems - that makes sense! Yes it defaults to {} but only
in cases when it's irrelevant. Cool.

Re: additionalProperties though, what is the intended default
behaviour when using a type:object and declaring properties:{...}?
Does it default to false?

On Feb 21, 1:14 am, Xample <flavien.vol...@gmail.com> wrote:
> 1. At first the required is now placed into an Object description as an
> array in the draft4. (which is much better)
> 2. There is no additional items possible if the item is something, the
> additional item is only applicable when an array of items is provided and
> that we run out of schemas compared to the number of items to validate. In

> some way you can consider the *additionalItems* to be {} even if the *items*is a schema.

> 3. My thoughts are that it should have been added an "extends" which would

> override keys (in opposition to the current *extends* which currently acts
> more likely like an *include*)

[Francis Galiegue]

On Wed, Feb 22, 2012 at 05:12, David <japg...@gmail.com> wrote:
[...]

>
> Re: additionalProperties though, what is the intended default
> behaviour when using a type:object and declaring properties:{...}?
> Does it default to false?
>

No, additionalProperties defaults to an empty schema. The algorithm to
lookup the schema associated to an object key is as such:

* if a key exists by its exact name in "properties", then the key must
obey the relevant schema;
* if the key matches one or more keys in "patternProperties", then it
must also obey _all_ schemas defined by these keys;
* if and only if no schema has matched so far, the schema defined by
"additionalProperties" is considered.

If additionalProperties is false and the key has matched no schema so
far, then the JSON instance does not match against the schema.

Hope this helps,
--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

[Xample]

Hi, and concerning those "repetitions" (required items as an array), they are mandatory for several reasons:

1. This is a rule which applies to the properties of an object, therefore it place is within an object, not into its content.

2. Before, we were able to specify a "required" property in an irrelevant place for example within an array item which was a duplicate with minItems.

3. It will be obvious while writing your own validator that before the "required-array" we had to check for undefined items key which were stored into the schema content, which was a real problem for both optimization and implementation. Here we just look at this array and check in parallel if the keys are defined in the document.

[David]

Thanks for the info guys. That helps me understand why certain
decisions have been made.
Ok so now that I understand that, there are still one significant
issue in my opinion:

When describing required properties there's still going to be a need
for repetition, which will inevitably lead to mistakes of human-error,
especially when schemas get larger. To be specific, if you have 20
properties and all are required, there's still a danger that it's way
too easy to add a new property, change the name of one, etc. and
forget to update the required array. If you had to maintain such a
schema you'd get quite frustrated after a while and there are valid
scenarios in the wild where such data definitions are valid and the
most practical (so a refactoring is not feasible).

In fact I think there are going to be 4 common use cases around
required properties:
a - Nothing is required. <-- This is ok, it's the current default.
b - Everything is required. <-- HARD, ERROR-PRONE
c - Some are required. (like a whitelist) <-- This is ok using the
required-array as mentioned previously.
d - Some are optional, the rest is required. (like a blacklist) <--
HARD, ERROR-PRONE

Some solution ideas:
b could be easily solved by allowing a wildcard. eg. "required":"*" or
"required":"all"
d could be solved by some kind of construct similar to the v4-style
"required", but with inverse meaning. e.g. "requireAllExcept":
["a","b"]

[Xample]

I do not totally agree simply because you can forget an inner schema "required" the same way as adding one into the "properties required list"

But still, something like a regex could be useful for this:

"required":"REGEX PATTERN"

Or an array of regex

"required":["regularKey", "REGEX PATTERN"];

This is slower but covering most of the applications.

I would not deal at all with optional keys, they were present in draft2 but did have been removed in the 3rd.

[Francis Galiegue]

On Tue, Feb 28, 2012 at 11:02, Xample <flavien...@gmail.com> wrote:
> I do not totally agree simply because you can forget an inner schema
> "required" the same way as adding one into the "properties required list"
>
> But still, something like a regex could be useful for this:
> "required":"REGEX PATTERN"
> Or an array of regex
> "required":["regularKey", "REGEX PATTERN"];

And how would you go about discerning a regular key from a regex
pattern? Any string is valid as a key name...

[Xample]

<(0_o)> You're right we are not in javascript… (i.e. there is no /
regexForm/ in json) , and keeping the regex pattern as a standard
(involving escaping) would not be efficient at all.
-> "requiredPattern":["REGEXPATTERN","ANOTHER_ONE"] then…

[Armishev, Sergey]

Let's say my json file require array of integers. Array must be size of 4 and default value [0,0,0,300]. The only problem I have is to how define the default value.
"my4integerarray": {
"required": true,
"description": "array of 4 integers",
"type": "array",
"items": {
"title": "array value",
"type":"integer",
"minItems":4,
"maxItems":4
}
}
Now how to define "default"?
1."default":"0,0,0,300" - wrong . it is string
2."default":[0,0,0,300] - wrong . it means array with first element is an array with 4 integers

Any other ideas?
Greatly appreciate your help

-Sergey

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

[Francis Galiegue]

On Thu, Mar 1, 2012 at 04:22, Armishev, Sergey <sarm...@idirect.net> wrote:
> Let's say my json file require array of integers. Array must be size of 4 and default value [0,0,0,300]. The only problem I have is to how define the default value.
> "my4integerarray": {
>    "required": true,
>    "description": "array of 4 integers",
>    "type": "array",
>    "items": {
>        "title": "array value",
>       "type":"integer",
>       "minItems":4,
>       "maxItems":4
>    }
>  }
> Now how to define "default"?
> 1."default":"0,0,0,300" - wrong . it is string
> 2."default":[0,0,0,300] - wrong . it means array with first element is an array with 4 integers
>
> Any other ideas?

Your second guess is good. But your schema is not: minItems and
maxItems are "first-class" keywords for describing arrays. Similarly,
the default keyword should be at the top level of the schema. Your
schema should read:

{
"type": "array",
"items": {

"type": "integer"
},
"minItems": 4,

"maxItems": 4,
"default": [ 0, 0, 0, 300 ]
}

Hope this helps,

[Armishev, Sergey]

Thanks, Francis!
That works

-Sergey

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.

[Armishev, Sergey]

Now, more complicated question. Can I use JavaScript function inside my schema? Something like this

{
"type": "array",
"items": {
"type": "integer"
},
"minItems": 4,
"maxItems": 4,

"default": [ 0, 0, 0, SomeDefaults.getMyValue()]
}

This way I can use values defined in third party libraries

[Francis Galiegue]

On Thu, Mar 1, 2012 at 15:32, Armishev, Sergey <sarm...@idirect.net> wrote:
> Now, more complicated question. Can I use JavaScript function inside my schema? Something like this
> {
>    "type": "array",
>    "items": {
>        "type": "integer"
>    },
>    "minItems": 4,
>    "maxItems": 4,
>    "default": [ 0, 0, 0, SomeDefaults.getMyValue()]
> }
>
> This way I can use values defined in third party libraries
> -Sergey
>

Strictly speaking, you can't. JSON Schema is language agnostic (I
implement it in Java for instance, but implementations exist in Ruby,
PHP, C++...).

What you can do, however, is use JavaScript to build the schema and
then feed it to a validator.

[Armishev, Sergey]

Another question regarding merging default array and json schema. When I have json file and json schema that it based on then I should not worry about default values. My software should take those default values from schema and merge to the report if report doesn't have it. The software that I am using (JavaScript onde) merges correctly scalars but not arrays (see below). Do you think it is software implementation problem or JSON schema feature? Francis, , how it works in your Java implementation?

Scalar:
{}
And
{
"title": "deafult integer",
"type": "object",
"properties": {
"my1integers":{
"required":true,
"description": "Single integer",
"default":0
}
}
}

Generates
{
"my1integers": 0
}

But
{}
and
{
"title": "deafult array of integers",
"type": "object",
"properties": {
"my4integers":{
"required":true,
"description": "Array of 4 integers",
"type": "array",
"items": {
"title": "Array values",

"type":"integer"
},
"minItems":4,

"maxItems":4,
"default":[0,0,0,300]
}
}
}

Throws error exception

-----Original Message-----
From: json-...@googlegroups.com [mailto:json-...@googlegroups.com] On Behalf Of Francis Galiegue
Sent: Thursday, March 01, 2012 3:13 AM
To: json-...@googlegroups.com
Subject: Re: [json-schema] default value for an array

--

You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.

[Francis Galiegue]

On Thu, Mar 1, 2012 at 21:00, Armishev, Sergey <sarm...@idirect.net> wrote:
> [...] Francis, , how it works in your Java implementation?
>

My implementation is a pure validator, it does not alter its inputs in
any way. That is for when I decide on implementing JSON patch ;) Not
today, though...