"additionalPatternProperties": validate properties by pattern, excluding ones listed in "properties"

[dmikov]

I encountered a very cumbersome issue, which might be related to implementation of validators, but the ones I tried all do it.

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "properties": {
        "version": {
            "type": "string"
        },
        "image64":{
            "type": "string"
        }
    },
    "required": [
        "version"
    ],
    "patternProperties": {
        "^[A-Za-z0-9_]+$": {
            "title": "Task Name"
            "type": "object",
            "properties": {
                "action":{
                    "type": "string"
                },
                "schedule": {
                    "type": "object",
                    "properties": {
                        "timedelta": {
                            "type": "object",
                            "properties": {
                                "minutes": {
                                    "type": "integer"
                                }
                            },
                            "required": [
                                "minutes"
                            ]
                        }
                    },
                    "required": [
                        "timedelta"
                    ]
                }
            }
        }
    }
}

The version and image64 property fail validation since they are catched by regex on pattern and therefore must be object and not string. Yes I can write a regex excluding them, but what happen if I need to add one more static property? Edit it again. I think requiring evaluation of static properties first should be mandatory to avoid this issue.

[handrews]

There is intentionally no order to properties vs patternProperties. It is effectively an allOf if the property name matches both.

Something like propertyNames could help express the concept of "except these properties" which is currently difficult to do- right now you can only "exclude" properties by doing something like {"not": {"properties": {"a": {}, "b": {}}}} which means they can't be there at all.

[dmikov]

I don't understand, the link you provided actually specifies the order. Property->PatternProperty->AdditionalProperties. Am I reading it wrong?

8.3.3.2. First step: schemas in "properties"

If set "p" contains value "m", then the corresponding schema in "properties" is added to "s".

[handrews]

"s" is the set of schemas against which to validate the child schema.

Step 1: If there's a match in properties, add that schema to "s"
Step 2: If there are any matches in patternProperties, add all of those schemas to "s"
Step 3: If and only if "s" is empty, add the additionalProperties schema to "s" (or fail validation if additionalProperties is false)

Implicit step 4: Validate the child instance against all schemas in "s" (effectively, an "allOf": [s0, s1, s2...])

[awwright]

@dmikov A property can be evaluated by both "properties" and "patternProperties", and there's no order to keywords, so the validation result isn't effected by which one the validator considers first.

Does that make sense?

[dmikov]

@awwright Hence my enhancement proposal. Why would you want to evaluate by both? Once you defined static property. Choosing specific over generic is a much more natural way. Kinda how lexers and tokenisers work.

[awwright]

Ok, so you'd like to see any matching properties in "patternProperties"
skipped if validated against one in "properties".

I'm not aware of anyone depending on the current behavior, though that
still seems like the more sensible approach to me.

Can you provide an example where your approach makes more sense?

On Oct 10, 2016 4:14 AM, "Dmitriy Krasnikov" notifications@github.com
wrote:

@awwright https://github.com/awwright Hence my enhancement proposal.
Why would you want to evaluate by both? Once you defined static property.
Choosing specific over generic is a much more natural way.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#76 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAatDVCImJUUBIYqyqeHHmf0yQaBh3aXks5qyh4mgaJpZM4KSJYM
.

[dmikov]

Gladly. I am developing workflow engine right now. As a workflow dsl language, we decided on Mistral DSL 2.0 http://docs.openstack.org/developer/mistral/dsl/dsl_v2.html

Here is an excerpt from it:

---
version: '2.0'

create_vm:
  description: Simple workflow example
  type: direct

  input:
    - vm_name
    - image_ref
    - flavor_ref
  output:
    vm_id: <% $.vm_id %>

  tasks:
    create_server:
      action: nova.servers_create name=<% $.vm_name %> image=<% $.image_ref %> flavor=<% $.flavor_ref %>
      publish:
        vm_id: <% task(create_server).result.id %>
      on-success:
        - wait_for_instance

    wait_for_instance:
      action: nova.servers_find id=<% $.vm_id %> status='ACTIVE'
      retry:
        delay: 5
        count: 15

As you can see the workflow name create_vm is a property name and will always have different name, but always same type definition. version and in my case schema (added for backward compatibility in the future) are static properties with type string. Using pattern property for workflow name doesn't work without excluding 'schema' and 'version' with positive lookahead regex. Which is painful and will be even more if I will want to add author or license in the future.

I personally can hardly find the case when combining rules from static and pattern property is beneficial. Whatever the goal is, this combination is just too unpredictable not to be dangerous, plus I imagine it can still be accomplished by combining multiple pattern properties, that would at least be somewhat expected behavior.

[jdesrosiers]

I'm against this for the same reasons @handrews laid out in #77. If we did this, it would make patternProperties as problematic as addtionalProperties is now. No validation keyword should be dependent on the value or validation result of another. We should be removing things like this not adding more.

[epoberezkin]

@jdesrosiers I actually disagree with the idea in #77, both in relation to maximum/minimum and also as a general approach. Allowing keyword validation depend on siblings is fine, it allows to keep keywords values shallower. Being religious about keyword independence is the opposite extreme of other proposed changes where keywords become aware not only of the siblings but of everything, this extreme is equally bad.
Why can't we leave things as they are and only change things that add or improve some functionality, rather than just change the syntax?

[epoberezkin]

Having said that, making patternProperties dependent on properties is not a bad idea - in many cases it is not possible to write a regular expression that would exclude a certain string. In some cases there are workarounds but they make schema very verbose, in some cases there isn't really.
So excluding properties from patternProperties (and also patternGroups) sounds like an enhancement.

[awwright]

Maybe we introduce another property called "additionalPatternProperties", keeping with the tradition of prefixing non-linear keywords with "additional".