Michael Staib

@benjie this is being explored. GraphQL-Java, GraphQL-DotNet, and HotChocolate have implemented a proposal that lets you introspect schema directives. https://github.com/graphql-java/graphql-java/pull/2221

@rivantsov It's about flexibility. We the intersection type you can combine types more flexibly and schema evolvability. @yaacovCR I think we should draw up some real use cases that show...

@romanivantsov it would be inconsistent with the spec text that states: > For example, given the following selection set to be executed serially: It looks at the execution behavior for...

There are not `Mutation sets` there are only selection sets. IMO its the smaller change to do. The section talks about selection sets and execution behavior, not about operations.

Or more clearly I would say its about the executor and how the executor will execute a given selection set. You would not have a mutation executor or a query...

GraphQL is specifically designed to be explicit. In general, this is not a good feature to have in the query engine since it makes the execution unpredictable. In tooling wildcards...

I agree, we should make it easier for the reader and refer to concrete sections that we refer to if possible. In the concrete case it would be content negotiation....

That the specs get out of date sometimes is not so much a problem, in these case we just need to check the changelog to verify and do PR to...

Sure, the thing here is that we started work on this SPEC in 2019 so references might get obsoleted by the time we are finished with it. Before we ratify...

> myField(arg: 5) # wrong! error! if it can be omitted, it should be omitted! If you do not implement a **should** your implementation is still valid. So, it is...