Add support for mixins/templates/inheritance in schema

[jakedt]

Often several models share the same set of relations and permissions. It would be nice if Authzed schema supported some kind of way of deduplicating these definitions, and possibly also for re-using that mechanism to simplify type declarations:

example:

mixin crud {
  relation editor: user
  relation viewer: user
  permission create = editor
  permission read = editor + viewer
  permission update = editor
  permission delete = editor
}

definition book {
   mixin crud
}

definition car {
  mixin crud 
}

definition movie {
  mixin crud 
}

and possibly:

definition anotherthing {
  relation crudable: crud
}

[CygnusBill]

I see this is pretty old as proposals go, but I would like to offer a comment just the same.

The idea is great as this would reduce the tedium of the repetitive definitions, but it will start to create new types in your type system, which is most elegant in its simplicity.

Here is a mix of a recent comment I made on combining multiple files and this idea:

// standard-operations.zed

definition standard_operations {
  relation editor: user
  relation viewer: user
  permission create = editor
  permission read = editor + viewer
  permission update = editor
  permission delete = editor
}

and,

// book.zed

import ./standard-operations.zed

definition book {
  ...standard_operations

  // ...
}

and,

// page.zed (needs to add to the definition ``book`` for some reason...

import ./book.zed

extend book {
  // new stuff here
}

This allows (and restricts to) two morphisms:

1. I want to include an existing definition in my definition
2. I want to extend an existing definition

The cost is adding the ellipsis operator and the keywords extend and import. It looks like all of these would be easily verified during the compilation. Each 'level' of the hierarchy retains complete control over its responsibilities. The abilities that can be included in the included definition case (1) can be complete, allowing no limit to the allowed definitions and aligning the requirements so the merge step can be shared completely with the extension case (2) as the they have the exact same needs and concerns.

The extension case as I covered in a separate comment, requires that no changes be allowed to modified definitions, only additions can be made. The team that created all of the original definition retains full control of that definition.

[benny-yamagata]

Just to bring this back up, my team has been using spice for a bit now and this some issue has come up time and time again. We have a set of relations/permissions that are standard across many object types, but each one also has their own unique elements that need to stay separate. IT bloats the schema to have each one redefine all of these everytime.

Any updates on this would be appreciated!