Jimmy - There's asymmetry between validation rules when providing a single literal where a list is expected and providing a single variable. The same coercion rules could be applied. This could help when evolving the APIs.
Lee - Could this lead to double-coercion and confusing behavior? How about the implications on performance? Do we want the full rules of scalar coercion here or just a subset? E.g. a single item to list seems OK with everyone, but how about int -> float?
Can't coerce variables at the beginning of the execution but on every use. Precompute all variations? Let's have an example implementation.
Seems obvious since directives are allowed everywhere else. Unanimously accepted :)
Can a value node have a directive? What to do with the ambiguity on what is the target of a directive? On a variable on a value?
Add a "stage number" to each RFC demarcating how far in the process it is. This should make it clear that the implementation and iteration comes before changing the spec. Despite something being obvious to the WG, changes should wait so the other implementers get a chance to see it,
Oleg - E.g. allow includeGraphQLSchema multiple times. Interestingly, both skip and include can be placed together. Should be fixed.
Make directive order significant.
What are the rules for combining directives? Boolean "OR"? Somehow explicitly declaring that is preferable.
Mark directives repeatable:
Option 1 - Only make skip/include unique per location. Not many people seem to be in favor of this one.
Option 2 - Decide uniqueness in directive definition. New keyword repeatable? Seems this is the way to go.
Discussion about whether repeatable is opt in or opt out. The general consensus was that repeatable was opt in.
The WG had consensus on the idea of ordering matters for repeatable directives.
https://github.com/graphql-cats/graphql-cats
Oleg talked about cats - the acceptance test framework
YAML files describing the compatibility tests. How to define errors/error types? Currently they're only text. Oleg introduced error mappings that correlate an error code to the spec defining it, the implementation and the associated message template. The templates may help with i18n of error messages.
Structured errors could enable better tooling suggestions, e.g. did you mean...
Existing implementations indicated that error codes in the spec would be useful to just help with identifying specific details.
How to deal with hierarchies, e.g multiple errors could be classified as parsing errors or coercion errors etc?
Ivan had concerns on avoiding deep coupling of error codes in the spec to behaviours.
Ivan discussed descriptions on schemas
Have a description both in SDL and introspection. Lee pointed out that changes to the introspection might have an impact on tooling.
Should GraphiQL do a 2-pass introspection, where it first introspects the introspection system (by introspecting __Schema) and then the rest? This would fix the current situation where it needs to fire an introspection query with subscriptions and then, in case of an error, try again without the subscriptions.
How about a new description that returns SDL?
Ivans points out that when a client encounters a custom scalar, they have no idea what to provide. Any value could arguably be given.
Introduce a new keyword as describing the custom scalar in terms of built-in ones, e.g.
scalar Url as String
Ivan proposed a conservative approach that scalar aliases can only be of well known defined graphql scalars.
Lee proposed the opposite where it can be open ended into a chain of scalars
E.g. Url as UTF8, UTF8 as String, or DateTime as Long (where Long is a new base type).
A new validation rule would need to prevent loops. A as B, B as A
Lee proposed that the chaining of scalars be a loop of 1. You can only create a scalar alias out of a scalar that itself is not a scalar alias.
Craig suggested a blog/newsletter/something listing new happenings (RFC etc) in GraphQL
Differentiating between input-only vs output-only vs both enums/scalars? This would allow safer schema evolution. E.g. a value removed from an output-only enum would not constitute a breaking change. While this is currently possible by careful design, a way to enforce this (and not accidentally use a type designated as an input-only as output) would be welcome.