Why does SchemaDefinition mandate { RootOperationTypeDefinition+ }?

[mjy9088]

What if someone wants to define a schema with only directives or a description, without RootOperationTypeDefinitions?

[martinbonnin]

@mjy9088 what would be the use case of doing so? A schema without any operation isn't really useful.

[martinbonnin]

only SchemaDefinition among TypeSystemDefinitionOrExtension enforces the { ... } block.

Don't objects and interfaces require a { ... } block as well? They are required to contain fields.

[mjy9088]

None of the ones you mentioned require fields in the specifications I have seen, if I interpreted these correctly.

• https://spec.graphql.org/October2021/#ObjectTypeDefinition
• https://spec.graphql.org/October2021/#ObjectTypeExtension
• https://spec.graphql.org/October2021/#InterfaceTypeDefinition
• https://spec.graphql.org/October2021/#InterfaceTypeExtension

[martinbonnin]

@mjy9088 lists are non-empty in the GraphQL spec. See https://spec.graphql.org/October2021/#sel-FARLJNCAACCrDgpe

A subscript suffix “list” is shorthand for a list of one or more of that symbol, represented as an additional recursive production.

[mjy9088]

Yes, at least one FieldDefinition is required in FieldsDefinition.

But the FieldsDefinition seems optional (with lookahead != {)

[martinbonnin]

Ah, yes indeed! TIL

[benjie]

In general we start with the tightest/strictest definitions and then open them up as the need arises. Since there has been no need for this to be opened up, we have not done so.

[mjy9088]

Thank you, the intention is clearly understood!