Roman Ivantsov

Using interfaces instead of 'Object types' - interesting approach, I think it works already as-is, and for backward compatibility we have to keep 'type' forever. abandoning input types - I...

it's illegal not because of loop of non-null references, but because there are no LEAF type fields!; if you make fields a and b nullable, you still won't be able...

@benjie and all I believe there's some confusion here, and it's my fault, it smashed two enhancements in one. The sentence I added ("This rule applies also...") - this is...

@benjie et al Coming back to this second sentence in current version: > Likewise, when representing a GraphQL schema using the type system definition language, a schema definition should be...

Again, sorry for the delay in response. Stuff keeps happening. I really appreciate your detailed responses, guys. @michaelstaib thank you for pointing out that 'should' is actually SHOULD, in the...

@benjie > Following the recommendations of the spec, whitespace aside, the same GraphQL schema should have the same representation in SDL independent of the tooling used to generate it. (Same...

+1 for void

I think it should be 'no repr in payload', just like with 'skip(if:true)'; if error - just same stuff, error object should appear in errors, path should include the field...

@spawnia, one option would be to do like c#: Void is an actual type in type system, 'void' is a keyword, equivalent of Void; (same as String type and string...

I agree that the spec should at least mention Subscriptions, regardless of if if describes some implementation over HTTP or not. Something like "Subscriptions are out of scope of this...