additionalProperties

[Ian Lewis]

Hello all,

The alpha version of the python json-schema validator does not currently check the additionalProperties property. I'm kind of curious what it's purpose is and what it's used for. The json-schema proposal 2nd draft says:

"This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value must be a schema. If false is provided, no additional properties are allowed, and the schema can not be extended. The default value is an empty schema which allows any value for additional properties. "

Does this mean that the properties defined here are validated just like any properties defined in the "properties" property? (I realize I used the word property a bit too much). How should they be validated?

Ian

[Kris Zyp]

The alpha version of the python json-schema validator does not currently check the additionalProperties property. I'm kind of curious what it's purpose is and what it's used for. The json-schema proposal 2nd draft says:

"This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value must be a schema. If false is provided, no additional properties are allowed, and the schema can not be extended. The default value is an empty schema which allows any value for additional properties. "

Does this mean that the properties defined here are validated just like any properties defined in the "properties" property? (I realize I used the word property a bit too much). How should they be validated?

Yes, they should. For example, if you had the schema:

 

{

    properties:{

        foo:{type:"string"}

    },

    additionalProperties:{type:"number"}

}

 

This would validate the following instance:

{

    foo:"hello",

    bar:4,

    baz:65

}

 

The "foo" property would be validated by the explicit property definition for foo, and "bar" and "baz" properties would be validated by the additionalProperties definition because there is no explicit definition in the properties object. If additionalProperties was omitted from the schema this instance would still be valid (additional properties can have any value by default), and if additionalProperties was set to false then the instance would be considered invalid (no additional properties are allowed besides "foo"). Does that make sense?

 

Kris

[Ian Lewis]

Ok,

Ok, I get it. I guess you would use this kind of thing so you could have a lot of unspecified properties of the same type in your schema. Was there a specific use case where it was envisioned this would be used?

Ian

2008/8/18 Kris Zyp <kri...@gmail.com>

[Kris Zyp]

Yes, this is used in situations where the data type uses an object as name value pairs where the names are user supplied and the value has a specific format. This is actually necessary for the self-descriptive schema for JSON schema (http://json-schema.org/schema), since the properties object has values with a certain structure (the schema structure), but the names can be anything. Setting it to false is useful when the object should not be allowed to have extra properties.

Kris

[Kris Zyp]

Jacob wrote:
> Kris,
>
> I am confused about what additionalProperties should be. Should it be
> another schema or a set of properties?
>
It should be another schema.
> I am reading what you have said before that it should be another
> schema, but it is defined as below.
>
> "additionalProperties":{
> "type":["boolean","object"],
> "properties":{"$ref":"$.properties"},
> "description":"This provides a default property definition for

> all properties that are not explicitly defined in an object type

> definition.",
> "optional":true,
> "default":{}},
>
> Why is it not defined as
> "additionalProperties":{
> "type":["boolean","object"],
> "properties":{"$ref":"$"},
> "description":"This provides a default property definition for

> all properties that are not explicitly defined in an object type

> definition.",
> "optional":true,
> "default":{}},
>
Then the properties object would be resolved to the schema definition,
which I don't think makes sense. It should be a schema, and this defines
it as such be equating it's properties object with the properties object
of the schema definition's property object (defining that if it is an
object it has the same properties as a schema).

Or maybe you are looking at the schema.properties file in which case I
think there is a bug there...

Kris

> Thanks,
> Jacob Tomaw

>
> On Aug 18, 6:22 am, "Kris Zyp" <kris...@gmail.com> wrote:
>
>> Yes, this is used in situations where the data type uses an object as name value pairs where the names are user supplied and the value has a specific format. This is actually necessary for the self-descriptive schema for JSON schema (http://json-schema.org/schema), since the properties object has values with a certain structure (the schema structure), but the names can be anything. Setting it to false is useful when the object should not be allowed to have extra properties.
>> Kris
>>
>> ----- Original Message -----
>> From: Ian Lewis
>> To: json-...@googlegroups.com
>> Sent: Sunday, August 17, 2008 11:01 PM
>> Subject: Re: additionalProperties
>>
>> Ok,
>>
>> Ok, I get it. I guess you would use this kind of thing so you could have a lot of unspecified properties of the same type in your schema. Was there a specific use case where it was envisioned this would be used?
>>
>> Ian
>>

>> 2008/8/18 Kris Zyp <kris...@gmail.com>

[Jacob Tomaw]

OK,

I see where my mistake is.

I read $.properties as being $.properties.properties.  I think I understand now.

Additional question about additional properties.  The JS JSON validator we are using (I think it is the one linked to in the proposal) only validated additionalProperties if properties are also defined.  Should additional properties be validated even if there are not properties defined?

Should the schema
{"additionalProperties":{"type":"string"}}
validate
{"prop1":false}

I say no, but the validator says yes.  For it to fail the schema must be
{"properties":{},"additionalProperties":{"type":"string"}}

Thanks,
Jacob

--
Jacob Tomaw
tfl:The Flatiron Life (http://tomaw.com)
Follow me on Twitter! (http://twitter.com/JacobTomaw)

[Kris Zyp]

Jacob Tomaw wrote:
> OK,
>
> I see where my mistake is.
>
> I read $.properties as being $.properties.properties. I think I
> understand now.
>
> Additional question about additional properties. The JS JSON
> validator we are using (I think it is the one linked to in the
> proposal) only validated additionalProperties if properties are also
> defined. Should additional properties be validated even if there are
> not properties defined?
>
> Should the schema
> {"additionalProperties":{"type":"string"}}
> validate
> {"prop1":false}
>
> I say no, but the validator says yes. For it to fail the schema must be
> {"properties":{},"additionalProperties":{"type":"string"}}

You are correct, "additionalProperties" should be applied even when
"properties" is not present and your first example should be rejected.
Looks like a bug in the schema implementation, I will take a look at
that (assuming you are using the one I wrote).
Kris

> <mailto:kris...@gmail.com>> wrote:
> >
> >> Yes, this is used in situations where the data type uses an
> object as name value pairs where the names are user supplied and
> the value has a specific format. This is actually necessary for
> the self-descriptive schema for JSON schema
> (http://json-schema.org/schema), since the properties object has
> values with a certain structure (the schema structure), but the
> names can be anything. Setting it to false is useful when the
> object should not be allowed to have extra properties.
> >> Kris
> >>
> >> ----- Original Message -----
> >> From: Ian Lewis
> >> To: json-...@googlegroups.com
> <mailto:json-...@googlegroups.com>
> >> Sent: Sunday, August 17, 2008 11:01 PM
> >> Subject: Re: additionalProperties
> >>
> >> Ok,
> >>
> >> Ok, I get it. I guess you would use this kind of thing so you
> could have a lot of unspecified properties of the same type in
> your schema. Was there a specific use case where it was envisioned
> this would be used?
> >>
> >> Ian
> >>

> >> 2008/8/18 Kris Zyp <kris...@gmail.com <mailto:kris...@gmail.com>>