Ban unknown properties mode (v5 proposal)

[JackKelly]

I'm new to the world of JSON-Schema but I'm really enjoying jsonschema; thanks so much for sharing.

I was just wondering if you have any plans to implement the v5 proposal to ban unknown properties?

[Julian]

Hey!

I've been cautiously eying the proposal as @geraintluff works on the specification for draft 5. I haven't been following that closely yet, but my concerns with that particular part of the proposal thankfully seem to align with some that @fge just brought up in json-schema/json-schema#120 – namely that I very much don't like that a single schema has different meanings depending on which mode you validate it in.

I definitely get the problem that we're trying to solve though.

My current inclination is that if you want something like that, I'd recommend doing schema pre-processing, which is probably how I'd implement that if something like ban unknown properties became a real thing as opposed to something more like Francis' proposal.

Here's a possible start (which undoubtedly has some small issues):

def combine(schema):
    properties = schema.setdefault("properties", {})
    subschemas = [schema]
    while subschemas:
        subschema = subschemas.pop()
        properties.update(
            (property, {}) for property in subschema.get("properties", ())
        )
        subschemas.extend(subschema.get("allOf", ()))
        subschemas.extend(subschema.get("anyOf", ()))
        subschemas.extend(subschema.get("oneOf", ()))

    schema["additionalProperties"] = False


schema = {
        "properties": {},
        "allOf": [
            {"properties": {"foo": {"type": "string"}}},
            {"properties": {"bar": {"type": "integer"}}},
        ],
        "oneOf": [
            {
                "anyOf": [
                    {"properties": {"quux": {"type": "string"}}},
                    {"properties": {"eggs": {"type": "string"}}},
                ]
            },
            {"properties": {"baz": {"type": "object"}}},
        ]
}
combine(schema)
print schema

[fge]

Just as a side note: in my own project, I've had a bucketload of bugs open due to the misunderstandings of "inheritance" as meant by JSON Schema, even when my implementation only supported draft v3.

@Julian I thank you for agreeing with me on the basic principle that this particular proposition is "bad" :p I'd really like some fuel here. I have lost the "id" battle, but maybe this battle can be won! After all, json-patch-merge is very simple...

[gazpachoking]

I completely agree that a separate mode not defined in the schema is not a
good idea.
On Mar 2, 2014 11:28 AM, "Francis Galiegue" notifications@github.com
wrote:

Just as a side note: in my own project, I've had a bucketload of bugs open
due to the misunderstandings of "inheritance" as meant by JSON Schema, even
when my implementation only supported draft v3.

@Julian https://github.com/Julian I thank you for agreeing with me on
the basic principle that this particular proposition is "bad" :p I'd really
like some fuel here. I have lost the "id" battle, but maybe this battle can
be won! After all, json-patch-merge is very simple...

Reply to this email directly or view it on GitHubhttps://github.com//issues/150#issuecomment-36458387
.

[JackKelly]

wow, thanks loads for all the responses! Very interesting discussion!

For my own project... for now, I think I'll just relax and let people define additional properties if they want. Then, after JSON-Schema v5 solidifies, I'll re-visit this issue, perhaps using @Julian's excellent code suggestion. Thanks again everyone.

[JackKelly]

If anyone's interested, I built a simple solution for this problem based heavily on @Julian's code. It's the 'combine' function here: https://github.com/nilmtk/nilm_metadata/blob/master/nilm_metadata/schema_preprocessing.py

[Julian]

Cool, looks good :)