Limitations of dependencies

[pospi]

Hi everyone,

I've been trying to change field definitions based on criteria in their dependencies but I don't believe this is an intended application with dependencies in the current state (03) of the draft.

A fairly common constraint I've been encountering is that a field may be required if the value of another field is set to a particular value. It's also fairly common for defaults and other field properties to change like this as well.

For example, consider an address format where the postcode may be omitted for a certain country (in this example, New Zealand).

I'm just spitballing here, but a good way of achieving these constraints (and potentially many others) may be to allow dependencies to affect the properties of the schema they were declared within. Now it probably isn't the best or most effective way of doing it, but as an example consider allowing dependencies to be arrays of (two) objects and let's call that format a "conditional dependency":

{
    "description"   : "An address...",
    "type" : "object",
    "properties" : {
        "postcode": {
            "type" : "string",
            "required" : true,           // postcode should be required by default  
            "dependencies" : [
                {                        // if this dependency schema matches...
                    "country" : {       
                        "enum" : ["NZ", "NZL", "NEW ZEALAND"]
                    }
                },
                {                        // ...override the field's properties with these ones
                    "required" : false   
                }
            ]
        },
        "country": {
            "type" : "string",
            "enum" : [
                // various country codes and names...
            ]
        }
    }
}


thoughts?

[Francis Galiegue]

The way I'd do this is something along these lines:

----

{
"description": "An address...",
"type": "object",
"properties": {

"country": {
"required": "true"
},
"postcode": {
"type": "string"
}
},
"extends": {
"type": [ { "$ref": "#/nz" }, { "$ref": "#/other" } ]
},
// definitions for nz: allow a few values for the "country" property
"nz": {
"properties": {

"country": {
"enum" : [ "NZ", "NZL", "NEW ZEALAND" ]
}
}
},

// definitions for other countries than nz: disallow nz "country"
property values, and make "postcode" mandatory
"other": {
"properties": {
"country": {
"type": "string",
"disallow": [ { "$ref": "#/nz/properties/country" } ]
},
"postcode": {
"required": true
}
}
}
}
----

What the draft doesn't say either is whether the above is legal at all
(is it? I believe it is, but cannot "prove" it)... Right now my
implementation considers this illegal because "other" and "nz" are
unknown keywords, but then they are fully addressable using JSON
Pointer as the "extends" and "disallow" above shows. I may change (in
fact, I think I will change) my implementation to allow this kind of
thing, otherwise it requires that these be in two separated schemas.
And it allows subschema addressing anyway, so...

[NB: comments are not allowed in the JSON grammar -- although many
parsers allow for C++-style comments as you, and I, wrote them]

--
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)

[Joe Littlejohn]

Francis,

The meta schema does allow additional properties for a schema:

https://github.com/kriszyp/json-schema/blob/master/draft-04/schema

So I believe the draft _does_ make your example legal (and you're
right to change your implementation). There's no requirement that the
properties of a schema should all be recognised as JSON Schema
keywords.

> --
> 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 Tue, Feb 7, 2012 at 13:37, Joe Littlejohn <joelit...@gmail.com> wrote:
> Francis,
>
> The meta schema does allow additional properties for a schema:
>
> https://github.com/kriszyp/json-schema/blob/master/draft-04/schema
>

Yes, indeed... There is no "additionalProperties": false in there.

However, in this blob, I still maintain the "id": "#simple-type"
should be illegal, for reasons I already mentioned. I'd really like
some input/thoughts on that.