From 979278e1e15d3ae198f26db195a328ea471607d4 Mon Sep 17 00:00:00 2001 From: Aaron Eline Date: Mon, 5 Feb 2024 15:14:16 -0500 Subject: [PATCH 01/11] RFC for schema annotations --- text/0046-schema-annotations.md | 141 ++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 text/0046-schema-annotations.md diff --git a/text/0046-schema-annotations.md b/text/0046-schema-annotations.md new file mode 100644 index 00000000..24fc0c94 --- /dev/null +++ b/text/0046-schema-annotations.md @@ -0,0 +1,141 @@ +# Annotations for Schemas + +## Related issues and PRs + +- Reference Issues: +- Implementation PR(s): + +## Timeline + +- Started: 2024-02-05 + +## Summary + +Like Cedar policies, users may want to associate arbitrary, machine readable metadata with Schema objects. +We solved this problem in Cedar Policies by allowing for *annotations*: arbitrary key/value pairs that are attachable to policies. +This could be extended to Cedar Schemas, allowing users to attach attributes an entity type, common type, and action definitions. + + +## Basic example + +1. Doc comments +``` +@doc("This entity defines our central user type") +entity User { + owner : User, + team : String +} +``` + +``` +@doc("Stop users from accessing a high security documents unless they are in the same building") +forbid(principal, action, resource) when { + resource.security_level == "HIGH" +unless { + resource.location == principal.location +}; +``` + +## Motivation + +Users should be allowed to associate machine readable metadata with objects in a Schema. +While we could create special syntax for associating particular kinds of metadata, we cannot +predict all of the metadata uses that users will have. +Thus providing a flexible system that users can adapt to their needs is preferrable. +This proposal re-uses the same syntax from Cedar Policies, creating a unified syntax. + + +## Detailed design + +### Semantics +Attributes have **no** impact on validation decisions. +Attributes are arbitrary key/value pairs where: +* 'key' is a valid Cedar identifier +* 'value' is a Cedar string + + +The Cedar spec takes no opinion or stance on the interpretation of annotations. +The interpretation is entirely up to users of Cedar. + +### Human Readable Syntax +Attributes in Cedar Schemas will mirror the syntax used for attributes in a policy: informally that's `@("value")`. +Formally the following rule is added to the Cedar grammar: +``` +Annotation := '@' IDENT '(' STR ')' +Annotations := Annotation {Annotations} +``` +With an arbitrary number of them being able to prepend to a top level declaration in a schema. + +Thus the full schema syntax becomes: +``` +Schema := {Namespace} +Namespace := ('namespace' Path '{' {Decl} '}') | {Decl} +Decl := Entity | Action | TypeDecl +Entity := Annotations 'entity' Idents ['in' EntOrTyps] [['='] RecType] ';' +Action := Annotations 'action' Names ['in' (Name | '[' [Names] ']')] [AppliesTo] [ActAttrs]';' +TypeDecl := Annotations 'type' IDENT '=' Type ';' +Type := PRIMTYPE | IDENT | SetType | RecType +EntType := Path +SetType := 'Set' '<' Type '>' +RecType := '{' [AttrDecls] '}' +AttrDecls := Name ['?'] ':' Type [',' | ',' AttrDecls] +AppliesTo := 'appliesTo' '{' AppDecls '}' +ActAttrs := 'attributes' '{' AttrDecls '}' +AppDecls := ('principal' | 'resource') ':' EntOrTyps [',' | ',' AppDecls] + | 'context' ':' RecType [',' | ',' AppDecls] +Path := IDENT {'::' IDENT} +EntTypes := Path {',' Path} +EntOrTyps := EntType | '[' [EntTypes] ']' +Name := IDENT | STR +Names := Name {',' Name} +Idents := IDENT {',' IDENT} +Annotation := '@' IDENT '(' STR ') +Annotations := Annotation {Annotations} + +IDENT := ['_''a'-'z''A'-'Z']['_''a'-'z''A'-'Z''0'-'9']* - PRIMTYPE +STR := Fully-escaped Unicode surrounded by '"'s +PRIMTYPE := 'Long' | 'String' | 'Bool' +WHITESPC := Unicode whitespace +COMMENT := '//' ~NEWLINE* NEWLINE +``` + +### JSON Syntax +None of the three top-level constructs (EntityTypes, Actions, CommonTypes) in schemas allow for arbitrary key/value pairs. +This means a new key can be safely added while preserving backwards compatibility. +This proposal reserves the `annotations` key at the top level of each of those constructs, which contains an Object, containing each annotation key as an Object key, associated with the annotation value. +The only oddness here is Common Types, whose toplevel is a regular type. While this should still be backwards compatible, it will look a little odd to have annotations in some types and not in others. + +### Human Readable Syntax + +## Drawbacks + +1. Complexity: adds more complexity to schema +2. Oddness around syntax for Common Types in JSON form +3. By not taking a stance on annotation meanings, it makes it harder for a standard to form around them (ex: for doc strings) +4. Multi-line docstrings are technically valid but awkward. + +## Alternatives + +### Take a stance +Reverse our decision around annotations and start taking stances on what annotations mean. +This lets us standardize certain annotations, like `doc`. +This probably can't happen unless we also do this for policies, which we've said we don't want to do. +### Doc Strings as comments +Instead of annotations, we could add "doc-strings" as a first class feature. +Could look like this: +``` +@doc("Stop users from accessing a high security documents unless they are in the same building") +/# Stop users from accessing a high security document unless: +/# A) The principal and user are at the same location +/# B) The principal has a job level greater than 4 +forbid(principal, action, resource) when { + resource.security_level == "HIGH" +unless { + (resource.location == principal.location) || (principal.job_level > 4 ) +}; +``` +This has nice and easy multi-line syntax, but is special cased and not as general. + +## Unresolved questions + +* If this RFC is accepted, do we want to patch [RFC24 (Schema Syntax](https://github.com/cedar-policy/rfcs/issues/24") to contain the full new grammar so it's in one place? From 6a93700806b2b2ed3d74818176322d708cbf5e48 Mon Sep 17 00:00:00 2001 From: Aaron Eline Date: Mon, 5 Feb 2024 15:17:09 -0500 Subject: [PATCH 02/11] move to 48 --- text/{0046-schema-annotations.md => 0048-schema-annotations.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0046-schema-annotations.md => 0048-schema-annotations.md} (100%) diff --git a/text/0046-schema-annotations.md b/text/0048-schema-annotations.md similarity index 100% rename from text/0046-schema-annotations.md rename to text/0048-schema-annotations.md From 4c4d61a7c7ea9408c45124bfe69e280d0d651d88 Mon Sep 17 00:00:00 2001 From: Aaron Eline Date: Mon, 5 Feb 2024 15:23:30 -0500 Subject: [PATCH 03/11] Typo --- text/0048-schema-annotations.md | 1 - 1 file changed, 1 deletion(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index 24fc0c94..6b87c35f 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -124,7 +124,6 @@ This probably can't happen unless we also do this for policies, which we've said Instead of annotations, we could add "doc-strings" as a first class feature. Could look like this: ``` -@doc("Stop users from accessing a high security documents unless they are in the same building") /# Stop users from accessing a high security document unless: /# A) The principal and user are at the same location /# B) The principal has a job level greater than 4 From 632931fd501b6cab126819325514d9d9e9af5441 Mon Sep 17 00:00:00 2001 From: John Kastner <130772734+john-h-kastner-aws@users.noreply.github.com> Date: Mon, 26 Feb 2024 11:58:00 -0500 Subject: [PATCH 04/11] Update text/0048-schema-annotations.md --- text/0048-schema-annotations.md | 1 - 1 file changed, 1 deletion(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index 6b87c35f..20009c67 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -105,7 +105,6 @@ This means a new key can be safely added while preserving backwards compatibilit This proposal reserves the `annotations` key at the top level of each of those constructs, which contains an Object, containing each annotation key as an Object key, associated with the annotation value. The only oddness here is Common Types, whose toplevel is a regular type. While this should still be backwards compatible, it will look a little odd to have annotations in some types and not in others. -### Human Readable Syntax ## Drawbacks From 06dad75cdecbb143fa702a06113637d19562c25f Mon Sep 17 00:00:00 2001 From: Mike Hicks Date: Wed, 28 Feb 2024 15:53:05 -0500 Subject: [PATCH 05/11] example tweak --- text/0048-schema-annotations.md | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index 20009c67..33db5356 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -18,23 +18,15 @@ This could be extended to Cedar Schemas, allowing users to attach attributes an ## Basic example -1. Doc comments +Here is a basic example for doc comments. ``` @doc("This entity defines our central user type") entity User { - owner : User, + manager : User, team : String -} -``` - -``` -@doc("Stop users from accessing a high security documents unless they are in the same building") -forbid(principal, action, resource) when { - resource.security_level == "HIGH" -unless { - resource.location == principal.location }; ``` +The `@id("...")` notation is similar to the notation used for policy annotations. ## Motivation From f124024259c2ab28333c95442c4bb47087e9b918 Mon Sep 17 00:00:00 2001 From: Shaobo He Date: Mon, 11 Nov 2024 11:45:46 -0800 Subject: [PATCH 06/11] Updates Signed-off-by: Shaobo He --- text/0048-schema-annotations.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index 33db5356..cda4a48a 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -1,9 +1,9 @@ -# Annotations for Schemas +# Annotations for Cedar Schemas ## Related issues and PRs - Reference Issues: -- Implementation PR(s): +- Implementation PR(s): https://github.com/cedar-policy/cedar/tree/feature/shaobo/rfc48 ## Timeline @@ -12,8 +12,8 @@ ## Summary Like Cedar policies, users may want to associate arbitrary, machine readable metadata with Schema objects. -We solved this problem in Cedar Policies by allowing for *annotations*: arbitrary key/value pairs that are attachable to policies. -This could be extended to Cedar Schemas, allowing users to attach attributes an entity type, common type, and action definitions. +We solved this problem in Cedar policies by allowing for *annotations*: arbitrary key/value pairs that are attachable to policies. +This could be extended to Cedar schemas, allowing users to attach attributes an entity type, common type, and action definitions. ## Basic example @@ -33,7 +33,7 @@ The `@id("...")` notation is similar to the notation used for policy annotations Users should be allowed to associate machine readable metadata with objects in a Schema. While we could create special syntax for associating particular kinds of metadata, we cannot predict all of the metadata uses that users will have. -Thus providing a flexible system that users can adapt to their needs is preferrable. +Thus providing a flexible system that users can adapt to their needs is preferable. This proposal re-uses the same syntax from Cedar Policies, creating a unified syntax. @@ -49,12 +49,12 @@ Attributes are arbitrary key/value pairs where: The Cedar spec takes no opinion or stance on the interpretation of annotations. The interpretation is entirely up to users of Cedar. -### Human Readable Syntax +### Cedar Schema Syntax Attributes in Cedar Schemas will mirror the syntax used for attributes in a policy: informally that's `@("value")`. Formally the following rule is added to the Cedar grammar: ``` Annotation := '@' IDENT '(' STR ')' -Annotations := Annotation {Annotations} +Annotations := {Annotations} ``` With an arbitrary number of them being able to prepend to a top level declaration in a schema. @@ -70,7 +70,7 @@ Type := PRIMTYPE | IDENT | SetType | RecType EntType := Path SetType := 'Set' '<' Type '>' RecType := '{' [AttrDecls] '}' -AttrDecls := Name ['?'] ':' Type [',' | ',' AttrDecls] +AttrDecls := Annotations Name ['?'] ':' Type [',' | ',' AttrDecls] AppliesTo := 'appliesTo' '{' AppDecls '}' ActAttrs := 'attributes' '{' AttrDecls '}' AppDecls := ('principal' | 'resource') ':' EntOrTyps [',' | ',' AppDecls] From 53180e2fcec6a8c08e63133b117fc8deb44b2139 Mon Sep 17 00:00:00 2001 From: Shaobo He Date: Mon, 11 Nov 2024 14:43:12 -0800 Subject: [PATCH 07/11] Updates Signed-off-by: Shaobo He --- text/0048-schema-annotations.md | 50 ++++++++++++++++++++++----------- 1 file changed, 34 insertions(+), 16 deletions(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index cda4a48a..c78dc007 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -20,11 +20,35 @@ This could be extended to Cedar schemas, allowing users to attach attributes an Here is a basic example for doc comments. ``` -@doc("This entity defines our central user type") -entity User { - manager : User, - team : String -}; +@doc("this is the namespace") +namespace TinyTodo { + @doc("a common type representing a task") + type Task = { + "id": Long, + "name": String, + "state": String, + }; + @doc("a common type representing a set of tasks") + type Tasks = Set; + + @doc("an entity type representing a list") + @doc("any entity type is a child of type `Application`") + entity List in [Application] = { + @doc("editors of a list") + "editors": Team, + "name": String, + "owner": User, + @doc("readers of a list") + "readers": Team, + "tasks": Tasks, + }; + + @doc("actions that a user can operate on a list") + action DeleteList, GetList, UpdateList appliesTo { + principal: [User], + resource: [List] + }; +} ``` The `@id("...")` notation is similar to the notation used for policy annotations. @@ -56,21 +80,22 @@ Formally the following rule is added to the Cedar grammar: Annotation := '@' IDENT '(' STR ')' Annotations := {Annotations} ``` -With an arbitrary number of them being able to prepend to a top level declaration in a schema. +With an arbitrary number of them being able to prepend to a namespace declaration, entity type declaration, common type declaration, action declaration, and an entity type attribute declaration. Thus the full schema syntax becomes: ``` Schema := {Namespace} -Namespace := ('namespace' Path '{' {Decl} '}') | {Decl} +Namespace := (Annotations 'namespace' Path '{' {Decl} '}') | {Decl} Decl := Entity | Action | TypeDecl -Entity := Annotations 'entity' Idents ['in' EntOrTyps] [['='] RecType] ';' +Entity := Annotations 'entity' Idents ['in' EntOrTyps] [['='] '{' [AnnotatedAttrDecls] '}'] ';' Action := Annotations 'action' Names ['in' (Name | '[' [Names] ']')] [AppliesTo] [ActAttrs]';' TypeDecl := Annotations 'type' IDENT '=' Type ';' Type := PRIMTYPE | IDENT | SetType | RecType EntType := Path SetType := 'Set' '<' Type '>' RecType := '{' [AttrDecls] '}' -AttrDecls := Annotations Name ['?'] ':' Type [',' | ',' AttrDecls] +AnnotatedAttrDecls := Annotations Name ['?'] ':' Type [',' | ',' AnnotatedAttrDecls] +AttrDecls := Name ['?'] ':' Type [',' | ',' AttrDecls] AppliesTo := 'appliesTo' '{' AppDecls '}' ActAttrs := 'attributes' '{' AttrDecls '}' AppDecls := ('principal' | 'resource') ':' EntOrTyps [',' | ',' AppDecls] @@ -91,13 +116,6 @@ WHITESPC := Unicode whitespace COMMENT := '//' ~NEWLINE* NEWLINE ``` -### JSON Syntax -None of the three top-level constructs (EntityTypes, Actions, CommonTypes) in schemas allow for arbitrary key/value pairs. -This means a new key can be safely added while preserving backwards compatibility. -This proposal reserves the `annotations` key at the top level of each of those constructs, which contains an Object, containing each annotation key as an Object key, associated with the annotation value. -The only oddness here is Common Types, whose toplevel is a regular type. While this should still be backwards compatible, it will look a little odd to have annotations in some types and not in others. - - ## Drawbacks 1. Complexity: adds more complexity to schema From 8ddb486dc9af15103e05ec990f41385884d5f679 Mon Sep 17 00:00:00 2001 From: Shaobo He Date: Mon, 11 Nov 2024 14:52:54 -0800 Subject: [PATCH 08/11] updated JSON schema format Signed-off-by: Shaobo He --- text/0048-schema-annotations.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index c78dc007..30c2b287 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -116,6 +116,13 @@ WHITESPC := Unicode whitespace COMMENT := '//' ~NEWLINE* NEWLINE ``` +### JSON Syntax +None of the three top-level constructs (EntityTypes, Actions, CommonTypes) in JSON schemas allow for arbitrary key/value pairs. +This means a new key can be safely added while preserving backwards compatibility. +The same fact also applies to entity attribute declarations. +This proposal reserves the `annotations` key at the top level of each of those constructs, which contains an Object, containing each annotation key as an Object key, associated with the annotation string. +The only oddness here is Common Types, whose toplevel is a regular type. While this should still be backwards compatible, it will look a little odd to have annotations in some types and not in others. + ## Drawbacks 1. Complexity: adds more complexity to schema From f6da7c1eb67764bf697dde39492208aba4bc29f2 Mon Sep 17 00:00:00 2001 From: Shaobo He Date: Mon, 11 Nov 2024 15:07:57 -0800 Subject: [PATCH 09/11] use annotations everywhere Signed-off-by: Shaobo He --- text/0048-schema-annotations.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index 30c2b287..c1d61b5a 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -13,7 +13,7 @@ Like Cedar policies, users may want to associate arbitrary, machine readable metadata with Schema objects. We solved this problem in Cedar policies by allowing for *annotations*: arbitrary key/value pairs that are attachable to policies. -This could be extended to Cedar schemas, allowing users to attach attributes an entity type, common type, and action definitions. +This could be extended to Cedar schemas, allowing users to attach attributes an entity type/common type/action declaration and attribute declaration. ## Basic example @@ -80,22 +80,21 @@ Formally the following rule is added to the Cedar grammar: Annotation := '@' IDENT '(' STR ')' Annotations := {Annotations} ``` -With an arbitrary number of them being able to prepend to a namespace declaration, entity type declaration, common type declaration, action declaration, and an entity type attribute declaration. +With an arbitrary number of them being able to prepend to a namespace declaration, entity type declaration, common type declaration, action declaration, and an attribute declaration. Thus the full schema syntax becomes: ``` Schema := {Namespace} Namespace := (Annotations 'namespace' Path '{' {Decl} '}') | {Decl} Decl := Entity | Action | TypeDecl -Entity := Annotations 'entity' Idents ['in' EntOrTyps] [['='] '{' [AnnotatedAttrDecls] '}'] ';' +Entity := Annotations 'entity' Idents ['in' EntOrTyps] [['='] RecType] ';' Action := Annotations 'action' Names ['in' (Name | '[' [Names] ']')] [AppliesTo] [ActAttrs]';' TypeDecl := Annotations 'type' IDENT '=' Type ';' Type := PRIMTYPE | IDENT | SetType | RecType EntType := Path SetType := 'Set' '<' Type '>' RecType := '{' [AttrDecls] '}' -AnnotatedAttrDecls := Annotations Name ['?'] ':' Type [',' | ',' AnnotatedAttrDecls] -AttrDecls := Name ['?'] ':' Type [',' | ',' AttrDecls] +AttrDecls := Annotations Name ['?'] ':' Type [',' | ',' AttrDecls] AppliesTo := 'appliesTo' '{' AppDecls '}' ActAttrs := 'attributes' '{' AttrDecls '}' AppDecls := ('principal' | 'resource') ':' EntOrTyps [',' | ',' AppDecls] From 6b5f4ea4984f527533e24135458aaad09fea79af Mon Sep 17 00:00:00 2001 From: Shaobo He Date: Tue, 12 Nov 2024 16:51:48 -0800 Subject: [PATCH 10/11] added a JSON schema example Signed-off-by: Shaobo He --- text/0048-schema-annotations.md | 101 +++++++++++++++++++++++++++++--- 1 file changed, 94 insertions(+), 7 deletions(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index c1d61b5a..ffe5b293 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -1,8 +1,8 @@ -# Annotations for Cedar Schemas +# Annotations for Cedar Schemas ## Related issues and PRs -- Reference Issues: +- Reference Issues: - Implementation PR(s): https://github.com/cedar-policy/cedar/tree/feature/shaobo/rfc48 ## Timeline @@ -24,6 +24,7 @@ Here is a basic example for doc comments. namespace TinyTodo { @doc("a common type representing a task") type Task = { + @doc("task id") "id": Long, "name": String, "state": String, @@ -32,7 +33,7 @@ namespace TinyTodo { type Tasks = Set; @doc("an entity type representing a list") - @doc("any entity type is a child of type `Application`") + @docComment("any entity type is a child of type `Application`") entity List in [Application] = { @doc("editors of a list") "editors": Team, @@ -56,7 +57,7 @@ The `@id("...")` notation is similar to the notation used for policy annotations Users should be allowed to associate machine readable metadata with objects in a Schema. While we could create special syntax for associating particular kinds of metadata, we cannot -predict all of the metadata uses that users will have. +predict all of the metadata uses that users will have. Thus providing a flexible system that users can adapt to their needs is preferable. This proposal re-uses the same syntax from Cedar Policies, creating a unified syntax. @@ -64,7 +65,7 @@ This proposal re-uses the same syntax from Cedar Policies, creating a unified sy ## Detailed design ### Semantics -Attributes have **no** impact on validation decisions. +Attributes have **no** impact on validation decisions. Attributes are arbitrary key/value pairs where: * 'key' is a valid Cedar identifier * 'value' is a Cedar string @@ -75,7 +76,7 @@ The interpretation is entirely up to users of Cedar. ### Cedar Schema Syntax Attributes in Cedar Schemas will mirror the syntax used for attributes in a policy: informally that's `@("value")`. -Formally the following rule is added to the Cedar grammar: +Formally the following rule is added to the Cedar grammar: ``` Annotation := '@' IDENT '(' STR ')' Annotations := {Annotations} @@ -122,6 +123,92 @@ The same fact also applies to entity attribute declarations. This proposal reserves the `annotations` key at the top level of each of those constructs, which contains an Object, containing each annotation key as an Object key, associated with the annotation string. The only oddness here is Common Types, whose toplevel is a regular type. While this should still be backwards compatible, it will look a little odd to have annotations in some types and not in others. +A corresponding JSON schema for the above example is as follows. +```JSON +{ + "": { + "annotations": { + "doc": "this is the namespace" + }, + "commonTypes": { + "Task": { + "annotations": { + "doc": "a common type representing a task" + }, + "type": "Record", + "attributes": { + "id": { + "type": "Long", + "annotations": { + "doc": "task id" + }, + }, + "name": { + "type": "String" + }, + "state": { + "type": "String" + } + } + }, + "Tasks": { + "type": "Set", + "element": { + "type": "Task" + } + } + }, + "entityTypes": { + "Application": {}, + "List": { + "annotations": { + "doc": "an entity type representing a list", + "docComment": "any entity type is a child of type `Application`" + }, + "memberOfTypes": [ + "Application" + ], + "shape": { + "type": "Record", + "attributes": { + "editors": { + "type": "Team" + }, + "name": { + "type": "String" + }, + "owner": { + "type": "User" + }, + "readers": { + "type": "Team" + }, + "tasks": { + "type": "Tasks" + } + } + } + } + }, + "actions": { + "CreateList": { + "annotations": { + "doc": "actions that a user can operate on a list" + }, + "appliesTo": { + "resourceTypes": [ + "Application" + ], + "principalTypes": [ + "User" + ] + } + } + } + } +} +``` + ## Drawbacks 1. Complexity: adds more complexity to schema @@ -133,7 +220,7 @@ The only oddness here is Common Types, whose toplevel is a regular type. While t ### Take a stance Reverse our decision around annotations and start taking stances on what annotations mean. -This lets us standardize certain annotations, like `doc`. +This lets us standardize certain annotations, like `doc`. This probably can't happen unless we also do this for policies, which we've said we don't want to do. ### Doc Strings as comments Instead of annotations, we could add "doc-strings" as a first class feature. From b1fbe74a7a52880e9886cbf035e79e5991272c54 Mon Sep 17 00:00:00 2001 From: shaobo-he-aws <130499339+shaobo-he-aws@users.noreply.github.com> Date: Tue, 19 Nov 2024 11:36:52 -0800 Subject: [PATCH 11/11] Update 0048-schema-annotations.md --- text/0048-schema-annotations.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/text/0048-schema-annotations.md b/text/0048-schema-annotations.md index ffe5b293..be4eac8b 100644 --- a/text/0048-schema-annotations.md +++ b/text/0048-schema-annotations.md @@ -236,7 +236,3 @@ unless { }; ``` This has nice and easy multi-line syntax, but is special cased and not as general. - -## Unresolved questions - -* If this RFC is accepted, do we want to patch [RFC24 (Schema Syntax](https://github.com/cedar-policy/rfcs/issues/24") to contain the full new grammar so it's in one place?