[Proposal] Add rules for framework independent conditional evaluation

[Anthropic]

Note: this is incomplete to use as example to kick off discussion
An ability to set options based on conditional logic formatted in a consistent way that can be implemented in all potential framework variations.

I implement this on my server, but something that covers this for both would be useful.

  "readonly": {
    "$$switch": {
      "$$options": [
        {
          "$$when": [ "workflow=/^(new|modify)$/" ],
          "$$then": false
        }
      ],
      "$$else": true
    }
  }

Even allowing RegEx for matching values.

There is also rules as defined in EclipseSource JSONForms as defined here: https://github.com/eclipsesource/jsonforms/blob/master/examples/app/local/local.controller.js#L58

   "rule":{
      "effect":"HIDE",
      "condition":{
         "type":"LEAF" ,
         "scope": {
            "$ref": "#/properties/personalData/properties/age"
         },
         "expectedValue":36
      }
   }

I propose a combination approach that allows a rule to define a set of value changes for the object.

"myfield": {
   "title": "My Field with rules",
   "key": "personalData.myfield",
   "rules": [
      {
         "condition": {
            "scope": { "$ref": "#/properties/personalData/properties/age" },
            "match": 36
         },
         "then": {
            "readonly": true,
            "hide": true,
            "default": 21
         }
      },
      {
         "condition": [
            {
               "scope": { "$ref": "#/properties/personalData/properties/role" },
               "patternMatch": "/^manager$/"
            },
            {
               "scope": { "$state": "access" },
               "match": "Admin"
            }
         ],
         "then": {
            "readonly": false,
            "hide": false,
            "model": 42
         }
      },
   ],
   "else": {
      "readonly": true,
      "hide": true,
      "default": 11
   }
}

All keywords, key, scope etc.. can be defined later...

[edgarmueller]

Hi,
a couple of comments from my side:

• In JSONForms we initally used the combination of scope & $ref to identify elements, but this is rather a technical issue, so I guess it'd be better to stick to a property like key in order to have a single property that can be used in an uniform fashion to identify elements within a schema. That said, the property value we are currently using to identify elements is based on JSON Pointer which I personally like better than the dot notation, since it is an existing standard and there is also framework support available to resolve refs (e.g. JsonRefs).
• I think condition should only take an object as a value, not an array, since semantics in that case wouldn't be clearly defined (should the effect only take place if all conditions evaluate to true? Or is a single one enough?). I'd instead rather propose to introduce additional types of conditions that enable composition of conditions via and and or constructs.
• I like the idea that effect/then takes an object that describes what happens if a condition is met. I'm not entirely sure whether I understand what default and model mean though.
• I'd get rid of the else clause since it actually describes the defaults and instead put the default values as properties of the field, i.e. something like

"myfield": {
   "title": "My Field with rules",
   "key": "<path-within-schema>",
   "readonly": true,
   "hide": true,
   "default": 11
}

• As you already mentioned wording should be fixed. The combination condition/then should probably be replaced with if/then or condition/effect to be more consistent.

Looking forward to discuss this with you guys!

[Anthropic]

@edgarmueller

1. I like the idea of using jsonref/pointers also, I was actually thinking conditions rules themselves could be ref'd in from #/rules so you can load them in and re-use them.
2. I see what you mean on condition array, I suppose in the nature of json-schema an object with support for anyOf/oneOf would read much better and still feel familiar?
3. default/model was a thought I had, if default it would not overwrite a preexisting value but model would overwrite. Again I'm not set on names, just didn't want to use 'set' or 'value' for some reason I can't remember.
4. Similarly the else clause was essentially to allow for values you may want to force rather than default. Additional parent properties could be advantageous for making this clearer. So a default:{...}, modify:{...} within the actions could clear that up.
5. I'm quite fond of when/then, but up for discussion :)

One of our members Nicklas made a point in a discussion on a full blown rules engine he wants to start with the appropriate name 'jsonrules', that remote rules would be useful, I tend to agree given where I work we are required to avoid making business logic public, he has some ideas on that and for a rules engine to be able to get what it would need from the core API. A discussion for another issue, but thought I'd mention it. There's potential to make rules a secondary schema the same way json-schema has the hypermedia-schema.

[nicklasb]

Hi,

Well, isn't what is being discussed here a "full blown" rules engine for json-schema-form?

My points are these:

1. We should keep the JSF standard as strict and scoped as possible
2. Rules are usable not only by JSF, but can be used all over the UI. And logically, would.
3. I rather implement some support for referencing those rules in JSF than actually implementing them there, significantly complicating JSF and raising the bar for implementation of the standard.
4. Furthermore, rules aren’t only usable in the UI, but across an organisation, at which moment they become business rules
5. I have looked around, and there is no simple, pragmatic notation for business rules. The BPMN stuff is super-complex and over-engineered.
6. To implement this outside JSF should not be very difficult. Especially the possibility to expand such a solution to use remotely set values.
7. It can’t be wrong when the logical domain is JSON RULES... jsonrules.org..

I feel that this would be both a faster, easier and less complicated way to implement rules than inside JSF.
Also I want to emphasize that I am not talking about some large project here, I want the rules standard and implementation only to have what is necessary, not more. Again to lessen the effort to implement it.

Perhaps it is a different issue, but just wanted to explain my reasoning.

[edgarmueller]

Hi,
sorry for the delay, last weeks were quite busy.
@nicklasb I agree with all your points, having a technology agnostic approach makes total sense and my first comment was rather meant to highlight what the requirements from our point of view would be.
What do you propose on how to proceed?
I feel like maybe someone of us should come up with an initial draft of such a schema that we could discuss and refine. What do you think? Maybe we could also derive a draft from existing schemas (e.g. like described in the examples above).