Support mixed operators with various direct assignments

[rhamzeh]

We had split supporting the following JSON from #16 to reduce scope as this still needed discussion.

As a suggestion, consider the following three cases:

I-

"relation": {
  "union": {
    "child": [
      {
        "computedUserset": {
          "relation": "rel3"
        }
      },
      {
        "difference": {
          "base": {
            "intersection": {
              "child": [
                {
                  "computedUserset": {
                    "relation": "rel1"
                  }
                },
                {
                  "computedUserset": {
                    "relation": "rel2"
                  }
                }
              ]
            }
          },
          "subtract": {
            "this": {}
          }
        }
      }
    ]
  }
}

II-

"relation": {
  "union": {
    "child": [
      {
        "intersection": {
          "child": [
            {
              "this": {}
            },
            {
              "computedUserset": {
                "relation": "allowed"
              }
            }
          ]
        }
      },
      {
        "difference": {
          "base": {
            "this": {}
          },
          "subtract": {
            "computedUserset": {
              "relation": "blocked"
            }
          }
        }
      }
    ]
  }
}

III-

"relation": {
  "difference": {
    "computedUserset": {
      "relation": "rel1"
    },
    "subtract": {
      "this": {}
    }
  }
}

Note: We should consider rejecting this case (define relation: rel1 but not [user]) as it is nonsensical

Some potential solutions: A. Allow restating the full type restrictions: e.g.

• define relation: rel3 or ((rel1 and rel2) but not [user])
• define relation: ([user] and allowed) or ([user] but not blocked)
• define relation: rel1 but not [user]

B. Allow using self e.g.

• define relation: [user] | rel3 or ((rel1 and rel2) but not self)
• define relation: [user] | (self and allowed) or (self but not blocked)
• define relation: [user] | rel1 but not self

C. Allow using self but require defining it for clarity (we can also have the define as optional) e.g.

• define relation: [user] as self | rel3 or ((rel1 and rel2) but not self)
• define relation: [user] as self | (self and allowed) or (self but not blocked)
• define relation: [user] as self | rel1 but not self

D. Allow defining an using an arbitrary name in lieu of self (needs an extension to the json to support it) e.g.

• define relation: [user] as some_name | rel3 or ((rel1 and rel2) but not some_name)
• define relation: [user] as some_name | (some_name and allowed) or (some_name but not blocked)
• define relation: [user] as some_name | rel1 but not some_name

Other questions to consider, does | as a separator make sense?

For other ideas, please post in the comments

Ref: Follow-up on https://github.com/openfga/language/issues/16

[rhamzeh]

At the moment, I am leaning for a combination of B and C (aka allowing both), on display we can always display C to ensure it is not confusing for people reading the DSL.

A is repetitive and possibly error prone D can be confusing and needs changes to the JSON to be implemented properly

Note: We should make sure both this and self are reserved words in the DSL and in the JSON validation