Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add clarifying note for composite and expand term #1078

Merged
merged 10 commits into from
Jun 6, 2024
8 changes: 6 additions & 2 deletions spec/Section 5 -- Validation.md
Original file line number Diff line number Diff line change
Expand Up @@ -446,7 +446,8 @@ SameResponseShape(fieldA, fieldB):
- If {typeA} or {typeB} is Scalar or Enum:
- If {typeA} and {typeB} are the same type return {true}, otherwise return
{false}.
- Assert: {typeA} and {typeB} are both composite types.
- Assert: {typeA} is an object, union or interface type.
- Assert: {typeB} is an object, union or interface type.
- Let {mergedSet} be the result of adding the selection set of {fieldA} and the
selection set of {fieldB}.
- Let {fieldsForName} be the set of selections with a given response name in
Expand All @@ -455,6 +456,9 @@ SameResponseShape(fieldA, fieldB):
- If {SameResponseShape(subfieldA, subfieldB)} is {false}, return {false}.
- Return {true}.

Note: In prior versions of the spec the term "composite" was used to signal a
type that is either an Object, Interface or Union type.

**Explanatory Text**

If multiple field selections with the same response names are encountered during
Expand Down Expand Up @@ -910,7 +914,7 @@ fragment inlineNotExistingType on Dog {
}
```

#### Fragments on Composite Types
#### Fragments on Object, Interface or Union Types

**Formal Specification**

Expand Down