Open rhamzeh opened 9 months ago
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
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-
II-
III-
Note: We should consider rejecting this case (
define relation: rel1 but not [user]
) as it is nonsensicalSome 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