> On Wed, Apr 18, 2012 at 09:25, Andrei Neculau <andrei.necu...@gmail.com>
> wrote:
> > Can you extend a model and declare a property as "undefined" ?
> > Otherwise, I guess one has to declare a subset schema - the common
> > denominator.

> Care to give an example of what you want to achieve? You cannot
> declare a property as "undefined" currently, you can only specify that
> you don't want any additional properties than the ones you declare in
> "properties" (by name) or "patternProperties" (by regex matching).

> --
> Francis Galiegue, fgalie...@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)

> {
>  "id": "address2",
>  "extends": "address",
>  "properties": {
>   "first_name": {
>    "type": "undefined"
>   },
>   "last_name": {
>    "type": "undefined"
>   },
>   "full_name": {}
>  }
> }

> If you create an instance of address2, it should not have any first_name,
> last_name properties, just full_name and street

> On Wed, Apr 18, 2012 at 09:45, Andrei Neculau <andrei.necu...@gmail.com>
> wrote:
> > {
> >  "id": "address",
> >  "properties": {
> >   "first_name": {}
> >   "last_name": {},
> >   "street": {}
> >  }
> > }

> > {
> >  "id": "address2",
> >  "extends": "address",
> >  "properties": {
> >   "first_name": {
> >    "type": "undefined"
> >   },
> >   "last_name": {
> >    "type": "undefined"
> >   },
> >   "full_name": {}
> >  }
> > }

> > If you create an instance of address2, it should not have any first_name,
> > last_name properties, just full_name and street

> And no other, right?

> In this case, you can do that:

> {
>     "extends" : { "$ref": "uri://to/address/schema" },
>     "properties": {
>         "full_name": {},
>         "street": {}
>     },
>     "additionalProperties": false
> }

> It means that the schemas for the full_name and street properties must
> be declared in the address schema. But be careful about IDs: "address"
> doesn't sound valid -- how do you, well, address it from outside the
> schema?

> --
> Francis Galiegue, fgalie...@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)

> Otherwise your structure doesn't make sense to me:
> - you extend address2 with first_name, last_name, street (street you
> actually overwrite with a new definition)

> Am I wrong to think that?

> No, I don't. Extending a schema does _not_ mean that you replace the
> schema for a given property, but that you _add_ another schema which
> the property must obey. When s2 extends s1, it means all constraints
> of s1 and s2 must be obeyed for a JSON instance to be considered
> valid.

> I'm thinking that the solution to my problem is just cherry-picking, rather
> than extending. Example
> {
>  "properties": {
>   "full_name": {}
>   "street": {
>    "$ref": "....../address#street
>   }
>  }
> }

> On Wed, Apr 18, 2012 at 10:33, Andrei Neculau <andrei.necu...@gmail.com>
> wrote:
> [...]
> > I think I am having a different understanding of additionalProperties.
> > I haven't use it so far, but I take its definition as = this schema is
> not
> > to be extended.

> OK, that's not quite true. I'll try to explain fully what
> additionalProperties means:

> * it has two valid values: either a JSON boolean (so, literally, false
> or true), or a schema. An empty schema is the equivalent of boolean
> value true;
> * "additionalProperties" is to be taken into consideration _if and
> only if_ a property:
>   * has no matching entry in "properties"; and
>   * does not obey any regex in "patternProperties".
> * when "additionalProperties" is false, this means that no other
> property than the ones defined in "properties" or "patternProperties"
> should exist in the instance;
> * the default value for "additionalProperties", if not present in the
> schema, is the empty schema (or boolean value true, which has pretty
> much the same effect).

> So, for instance, this:

> {
>     "type": "object",
>     "properties": {
>         "p": { //whatever schema here }
>     },
>     "additionalProperties": false
> }

> pretty much restricts an instance to be an object and only have one
> key, namely "p". As "additionalProperties" is set to false here, it
> means no other property than "p" can appear in an instance
> ("patternProperties" is not specified either).

> On the other hand, if "additionalProperties" was _not_ specified
> above, it would mean that if a key named "p" was present in the object
> instance, it'd have to obey the schema, regardless of other keys
> defined in the object (other keys would have to obey the empty schema,
> which validates each and every JSON document).

> I can explain some more on request. The relationship between
> "properties", "patternProperties" and "additionalProperties" is not a
> simple one...

> --
> Francis Galiegue, fgalie...@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)