Specification constraints

[sungam3r]

How to deal with spec constraints? For example this one

Transitively implemented interfaces (interfaces implemented by the interface that is being implemented) must also be defined on an implementing type or interface.

I know that we implement many checks in GraphQL.NET level. There is often more context for this and more convenient API. Nevertheless, the question arises to support the validation (at least some basic constraints) at the parser level. This can be a separate class with many validation rules such as one mentioned above that can be used if necessary. @Shane32 what do you think?

[Shane32]

I would leave the parsing to the parser and the validation to the validation framework within GraphQL.NET.

What I don’t like is that there is two distinct sets of AST classes - one within the parser and one within GraphQL.NET. You’d think we could create an AST library that both projects can use. Or simply use the parser AST classes for the GraphQL.NET library.

[sungam3r]

I do not like it either. In some issue we have already talked about that with @joemcbride . It seems to me that the second set of AST classes appeared by a design mistake. I don't remember.

[sungam3r]

#166 (comment) and #166 (comment)

[sungam3r]

What I don’t like is that there is two distinct sets of AST classes - one within the parser and one within GraphQL.NET. You’d think we could create an AST library that both projects can use. Or simply use the parser AST classes for the GraphQL.NET library.

Fixed :)

[sungam3r]

I close this issue. I agree that it's more appropriate to have such validations in GraphQL.NET repo.