From 2d60b336531c1c98c5c31f96051711499b2bec3d Mon Sep 17 00:00:00 2001 From: Mark Larah Date: Tue, 10 Dec 2024 11:40:13 -0600 Subject: [PATCH] prettier --- spec/Appendix B -- Grammar Summary.md | 2 + spec/Section 2 -- Language.md | 8 +- spec/Section 3 -- Type System.md | 120 ++++++++++++++------------ 3 files changed, 69 insertions(+), 61 deletions(-) diff --git a/spec/Appendix B -- Grammar Summary.md b/spec/Appendix B -- Grammar Summary.md index d0777aac5..22dab575e 100644 --- a/spec/Appendix B -- Grammar Summary.md +++ b/spec/Appendix B -- Grammar Summary.md @@ -44,6 +44,7 @@ Token :: - StringValue Punctuator :: + - DotPunctuator - OtherPunctuator @@ -420,6 +421,7 @@ TypeSystemDirectiveLocation : one of - `INPUT_FIELD_DEFINITION` SchemaCoordinate : + - Name - Name . Name - Name . Name ( Name : ) diff --git a/spec/Section 2 -- Language.md b/spec/Section 2 -- Language.md index 9646c867b..3c22f0e71 100644 --- a/spec/Section 2 -- Language.md +++ b/spec/Section 2 -- Language.md @@ -189,10 +189,10 @@ GraphQL documents include punctuation in order to describe structure. GraphQL is a data description language and not a programming language, therefore GraphQL lacks the punctuation often used to describe mathematical expressions. -The {`.`} punctuator must not be followed by a {`.`} or {Digit}. This -ensures that the source {"..."} can only be interpreted as a single {`...`} and -not three {`.`}. It also avoids any potential ambiguity with {FloatValue}. As -an example the source {".123"} has no valid lexical representation (without this +The {`.`} punctuator must not be followed by a {`.`} or {Digit}. This ensures +that the source {"..."} can only be interpreted as a single {`...`} and not +three {`.`}. It also avoids any potential ambiguity with {FloatValue}. As an +example the source {".123"} has no valid lexical representation (without this restriction it would have been interpreted as {`.`} followed by {IntValue}). ### Names diff --git a/spec/Section 3 -- Type System.md b/spec/Section 3 -- Type System.md index 89d7a80a6..ce75b331e 100644 --- a/spec/Section 3 -- Type System.md +++ b/spec/Section 3 -- Type System.md @@ -2168,26 +2168,27 @@ scalar UUID @specifiedBy(url: "https://tools.ietf.org/html/rfc4122") ## Schema Coordinates SchemaCoordinate : - - Name - - Name . Name - - Name . Name ( Name : ) - - @ Name - - @ Name ( Name : ) -:: A *schema coordinate* is a human readable string that uniquely identifies a -*schema element* within a GraphQL Schema. +- Name +- Name . Name +- Name . Name ( Name : ) +- @ Name +- @ Name ( Name : ) -:: A *schema element* is a specific instance of a named type, field, input +:: A _schema coordinate_ is a human readable string that uniquely identifies a +_schema element_ within a GraphQL Schema. + +:: A _schema element_ is a specific instance of a named type, field, input field, enum value, field argument, directive, or directive argument. -A *schema coordinate* is always unique. Each *schema element* may be referenced +A _schema coordinate_ is always unique. Each _schema element_ may be referenced by exactly one possible schema coordinate. There is a bidirectional 1:1 mapping. -A *schema coordinate* may refer to either a defined or built-in *schema element*. -For example, `String` and `@deprecated(reason:)` are both valid schema +A _schema coordinate_ may refer to either a defined or built-in _schema +element_. For example, `String` and `@deprecated(reason:)` are both valid schema coordinates which refer to built-in schema elements. However it must not refer -to a meta-field. For example, `Business.__typename` is *not* a valid -schema coordinate. +to a meta-field. For example, `Business.__typename` is _not_ a valid schema +coordinate. Note: Unions members are not valid schema coordinates since they are references to existing types in the schema. This preserves the 1:1 mapping property of @@ -2196,68 +2197,73 @@ schema coordinates as stated above. Note: A {SchemaCoordinate} is not a definition within a GraphQL {Document}, but a separate standalone grammar, intended to be used by tools to reference types, fields, and other *schema element*s. Examples include: as references within -documentation to refer to types and fields in a schema, a lookup key that can -be used in logging tools to track how often particular fields are queried in +documentation to refer to types and fields in a schema, a lookup key that can be +used in logging tools to track how often particular fields are queried in production. **Semantics** -To refer to a *schema element*, a *schema coordinate* must be interpreted in the +To refer to a _schema element_, a _schema coordinate_ must be interpreted in the context of a GraphQL {schema}. SchemaCoordinate : Name - 1. Let {typeName} be the value of the first {Name}. - 2. Return the type in the {schema} named {typeName}. + +1. Let {typeName} be the value of the first {Name}. +2. Return the type in the {schema} named {typeName}. SchemaCoordinate : Name . Name - 1. Let {typeName} be the value of the first {Name}. - 2. Let {type} be the type in the {schema} named {typeName}. - 3. If {type} is an Enum type: - 1. Let {enumValueName} be the value of the second {Name}. - 2. Return the enum value of {type} named {enumValueName}. - 4. Otherwise if {type} is an Input Object type: - 1. Let {inputFieldName} be the value of the second {Name}. - 2. Return the input field of {type} named {inputFieldName}. - 5. Otherwise: - 1. Assert {type} must be an Object or Interface type. - 2. Let {fieldName} be the value of the second {Name}. - 3. Return the field of {type} named {fieldName}. + +1. Let {typeName} be the value of the first {Name}. +2. Let {type} be the type in the {schema} named {typeName}. +3. If {type} is an Enum type: +4. Let {enumValueName} be the value of the second {Name}. +5. Return the enum value of {type} named {enumValueName}. +6. Otherwise if {type} is an Input Object type: +7. Let {inputFieldName} be the value of the second {Name}. +8. Return the input field of {type} named {inputFieldName}. +9. Otherwise: +10. Assert {type} must be an Object or Interface type. +11. Let {fieldName} be the value of the second {Name}. +12. Return the field of {type} named {fieldName}. SchemaCoordinate : Name . Name ( Name : ) - 1. Let {typeName} be the value of the first {Name}. - 2. Let {type} be the type in the {schema} named {typeName}. - 3. Assert {type} must be an Object or Interface type. - 4. Let {fieldName} be the value of the second {Name}. - 5. Let {field} be the field of {type} named {fieldName}. - 6. Assert {field} must exist. - 7. Let {fieldArgumentName} be the value of the third {Name}. - 8. Return the argument of {field} named {fieldArgumentName}. + +1. Let {typeName} be the value of the first {Name}. +2. Let {type} be the type in the {schema} named {typeName}. +3. Assert {type} must be an Object or Interface type. +4. Let {fieldName} be the value of the second {Name}. +5. Let {field} be the field of {type} named {fieldName}. +6. Assert {field} must exist. +7. Let {fieldArgumentName} be the value of the third {Name}. +8. Return the argument of {field} named {fieldArgumentName}. SchemaCoordinate : @ Name - 1. Let {directiveName} be the value of the first {Name}. - 2. Return the directive in the {schema} named {directiveName}. + +1. Let {directiveName} be the value of the first {Name}. +2. Return the directive in the {schema} named {directiveName}. SchemaCoordinate : @ Name ( Name : ) - 1. Let {directiveName} be the value of the first {Name}. - 2. Let {directive} be the directive in the {schema} named {directiveName}. - 3. Assert {directive} must exist. - 4. Let {directiveArgumentName} be the value of the second {Name}. - 5. Return the argument of {directive} named {directiveArgumentName}. + +1. Let {directiveName} be the value of the first {Name}. +2. Let {directive} be the directive in the {schema} named {directiveName}. +3. Assert {directive} must exist. +4. Let {directiveArgumentName} be the value of the second {Name}. +5. Return the argument of {directive} named {directiveArgumentName}. **Examples** -| Element Kind | *Schema Coordinate* | *Schema Element* | -| ------------------ | -------------------------------- | ----------------------------------------------------------------------- | -| Named Type | `Business` | `Business` type | -| Field | `Business.name` | `name` field on the `Business` type | -| Input Field | `SearchCriteria.filter` | `filter` input field on the `SearchCriteria` input object type | -| Enum Value | `SearchFilter.OPEN_NOW` | `OPEN_NOW` value of the `SearchFilter` enum | -| Field Argument | `Query.searchBusiness(criteria:)`| `criteria` argument on the `searchBusiness` field on the `Query` type | -| Directive | `@private` | `@private` directive | -| Directive Argument | `@private(scope:)` | `scope` argument on the `@private` directive | - -The table above shows an example of a *schema coordinate* for every kind of -*schema element* based on the schema below. +| Element Kind | _Schema Coordinate_ | _Schema Element_ | +| ------------------ | --------------------------------- | --------------------------------------------------------------------- | +| Named Type | `Business` | `Business` type | +| Field | `Business.name` | `name` field on the `Business` type | +| Input Field | `SearchCriteria.filter` | `filter` input field on the `SearchCriteria` input object type | +| Enum Value | `SearchFilter.OPEN_NOW` | `OPEN_NOW` value of the `SearchFilter` enum | +| Field Argument | `Query.searchBusiness(criteria:)` | `criteria` argument on the `searchBusiness` field on the `Query` type | +| Directive | `@private` | `@private` directive | +| Directive Argument | `@private(scope:)` | `scope` argument on the `@private` directive | + +The table above shows an example of a _schema coordinate_ for every kind of +_schema element_ based on the schema below. ```graphql type Query {