Fix spelling errors.

Author: gabrielf

README.md

@@ -10,16 +10,16 @@ This technical preview contains a draft specification for GraphQL and a referenc
 implementation in JavaScript that implements that draft,
 [GraphQL.js](https://github.com/graphql/graphql-js).
 
-The reference implemention provides base libraries in javascript that would
+The reference implementation provides base libraries in javascript that would
 provide the basis for full GraphQL implementations and tools. It is not a fully
 standalone GraphQL server that a client developer could use to start
 manipulating and querying data. Most importantly it provides no mapping to a
 functioning, production-ready backend. The only “backend” we have targeted for
 this early preview are in-memory stubs in test cases.
 
-We are releasing this now because after GraphQL was first discussed publically,
+We are releasing this now because after GraphQL was first discussed publicly,
 many engineers used this information to implement the parts of the system that
-we discussed publically. We want to support those engineers by providing both a
+we discussed publicly. We want to support those engineers by providing both a
 formal specification and a reference implementation for the system as a whole.
 
 To that end the target audience is not the client developer, but those who have
@@ -179,7 +179,7 @@ fields are non-null (since our current implementation has hard-coded data),
 we didn't mark them as non-null. One can imagine we would eventually
 replace our hardcoded data with a backend service, which might not be
 perfectly reliable; by leaving these fields as nullable, we allow
-ourselves the flexability to eventually return null to indicate a backend
+ourselves the flexibility to eventually return null to indicate a backend
 error, while also telling the client that the error occurred.
 
 ```

Section 1 -- Overview.md

@@ -36,7 +36,7 @@ platform for tool-building.
 
 GraphQL has a number of design principles:
 
- * **Hierarchal**: Most product development today involves the creation and
+ * **Hierarchical**: Most product development today involves the creation and
    manipulation of view hierarchies. To achieve congruence with the structure
    of these applications, a GraphQL query itself is structured hierarchically.
    The query is shaped just like the data it returns. It is a natural

Section 2 -- Language.md

@@ -196,7 +196,7 @@ the field's name otherwise.
 ## Input Values
 
 Both field arguments and directives accept input values. Input values can be
-specified as a variable or respresented inline as literals.  Input values can
+specified as a variable or represented inline as literals.  Input values can
 be scalars, enumerations, or input objects. List and inputs objects may also
 contain variables.
 
@@ -220,7 +220,7 @@ Whitespace is significant within a string.
 
 **Enum Value**
 
-Enum values are respresented as unquoted names (ex. `MOBILE_WEB`). It is
+Enum values are represented as unquoted names (ex. `MOBILE_WEB`). It is
 recommended that Enum values be "all caps". Enum values are only used in contexts
 where the precise enumeration type is known. Therefore it's not necessary
 to use the enumeration type name in the literal.

Section 3 -- Type System.md

@@ -40,7 +40,7 @@ GraphQL supports two abstract types: interfaces and unions.
 
 An `Interface` defines a list of fields; `Object` types that implement that
 interface are guaranteed to implement those fields. Whenever the type system
-claims it will return an interface, it will return a valid implementating type.
+claims it will return an interface, it will return a valid implementing type.
 
 A `Union` defines a list of possible types; similar to interfaces, whenever the
 type system claims a union will be returned, one of the possible types will be
@@ -51,7 +51,7 @@ string returns either null or a singular string. The type system might want to
 define that it returns a list of other types; the `List` type is provided for
 this reason, and wraps another type. Similarly, the `Non-Null` type wraps
 another type, and denotes that the result will never be null. These two types
-are refered to as "wrapping types"; non-wrapping types are refered to as
+are referred to as "wrapping types"; non-wrapping types are referred to as
 "base types". A wrapping type has an underlying "base type", found by
 continually unwrapping the type until a base type is found.
 
@@ -62,7 +62,7 @@ what data is expected from the client in these queries.
 ### Scalars
 
 As expected by the name, a scalar represents a primitive value in GraphQL.
-GraphQL responses take the form of a hierarchal tree; the leaves on these trees
+GraphQL responses take the form of a hierarchical tree; the leaves on these trees
 are GraphQL scalars.
 
 All GraphQL scalars are representable as strings, though depending on the
@@ -109,7 +109,7 @@ input values, and coercion rules may apply differently depending on which type
 of input value is encountered. GraphQL may be parameterized by query variables,
 the values of which are often serialized when sent over a transport like HTTP. Since
 some common serializations (ex. JSON) do not discriminate between integer
-and floating-point values, they are interpretted as an integer input value if
+and floating-point values, they are interpreted as an integer input value if
 they have an empty fractional part (ex. `1.0`) and otherwise as floating-point
 input value.
 
@@ -229,8 +229,8 @@ values (such as `4.0`), must raise a query error indicating an incorrect type.
 
 ### Objects
 
-GraphQL queries are hierarchal and composed, describing a tree of information.
-While Scalar types describe the leaf values of these hierarchal queries, Objects
+GraphQL queries are hierarchical and composed, describing a tree of information.
+While Scalar types describe the leaf values of these hierarchical queries, Objects
 describe the intermediate levels.
 
 GraphQL Objects represent a list of named fields, each of which yield a value of
@@ -630,7 +630,7 @@ literals must not be accepted as an enum input and instead raise a query error.
 Query variable transport serializations which have a different representation
 for non-string symbolic values (for example, [EDN](https://github.com/edn-format/edn))
 should only allow such values as enum input values. Otherwise, for most
-transport serializations that do not, strings may be interpretted as the enum
+transport serializations that do not, strings may be interpreted as the enum
 input value with the same name.
 
 

Section 4 -- Introspection.md

@@ -76,9 +76,9 @@ warnings.
 
 ### Type Name Introspection
 
-GraphQL supports type name introspection within at any point in a query by the
+GraphQL supports type name introspection at any point within a query by the
 meta field `__typename: String!` when querying against any Object, Interface,
-or Union. It returns the name of the object type currently being queryied.
+or Union. It returns the name of the object type currently being queried.
 
 This is most often used when querying against Interface or Union types to
 identify which actual type of the possible types has been returned.

Section 5 -- Validation.md

@@ -1,6 +1,6 @@
 # Validation
 
-GraphQL does not just verify if a request is syntatically correct.
+GraphQL does not just verify if a request is syntactically correct.
 
 Prior to execution, it can also verify that a request is valid
 within the context of a given GraphQL schema. Validation is primarily
@@ -296,7 +296,7 @@ query directQueryOnUnionWithoutSubFields
   * Let {arguments} be the set of argument provided to the {selection}
   * Let {targetField} be the target field of a given {selection}
   * Let {argumentDefinitions} be the set of argument definitions of {targetField}
-  * Each {argumentName} in {arguments} must have a corresponding argument defintion
+  * Each {argumentName} in {arguments} must have a corresponding argument definition
     in the {targetField} with the same name
 
 ** Explanatory Text **
@@ -363,9 +363,9 @@ fragment multipleArgsReverseOrder on Arguments {
   * Let {arguments} be the set of argument provided to the {selection}
   * Let {targetField} be the target field of a given {selection}
   * Let {argumentDefinitions} be the set of argument definitions of {targetField}
-  * For each {literalArgument} of all {arguements} with literal for values.
-    * The type of {literalArgument} must equal the type of the argument defintion OR
-    * The type of {literalArgument} must be coercable to type of the argument definition
+  * For each {literalArgument} of all {arguments} with literal for values.
+    * The type of {literalArgument} must equal the type of the argument definition OR
+    * The type of {literalArgument} must be coercible to type of the argument definition
 
 ** Explanatory Text **
 
@@ -374,7 +374,7 @@ literal is being passed to.
 
 This means either
   * the types must match equally or
-  * the types must be coercable.
+  * the types must be coercible.
 
 For example, an Int can be coerced into a Float.
 
@@ -388,7 +388,7 @@ fragment coercedIntIntoFloatArg on Arguments {
 }
 ```
 
-An uncoerceable conversion, is string to int. Therefore, the
+An incoercible conversion, is string to int. Therefore, the
 following example is invalid.
 
 ```!graphql
@@ -575,7 +575,7 @@ fragment nameFragment on Dog { name }
   * {DetectCycles(fragmentDefinition, visited)}
 
 {DetectCycles(fragmentDefinition, visited)} :
-  * Let {spreads} be all fragment spread descendents of {fragmentDefinition}
+  * Let {spreads} be all fragment spread descendants of {fragmentDefinition}
   * For each {spread} in {spreads}
     * {visited} must not contain {spread}
     * Let {nextVisited} be the set including {spread} and members of {visited}
@@ -746,7 +746,7 @@ can also never return meaningful results, making it invalid.
 
 ##### Abstract Spreads in Abstract Scope
 
-Union or interfaces fragments can be used within eachother. As long as there
+Union or interfaces fragments can be used within each other. As long as there
 exists at least *one* object type that exists in the intersection of the
 possible types of the scope and the spread, the spread is considered valid.
 
@@ -799,13 +799,13 @@ usage of a directive, the directive must be available on that server.
     * {directiveUse} must have an argument
   * Let {argumentType} be the type of argument supplied to {directiveUse}
   * {argumentType} and {directiveType} must be the same or {argumentType} must
-    be coercable to {directiveType}
+    be coercible to {directiveType}
 
 ** Explanatory Text **
 
 Directive arguments follow similar rules to arguments on fields. Much like
 field arguments, arguments to directives must be of the same type or
-coercable to input type of the directive type.
+coercible to input type of the directive type.
 
 Directives arguments differ from field arguments insofar as they can
 be used without a provided argument. If the type of directive is not non-null,
@@ -852,7 +852,7 @@ validation
 ```
 
 Default values must be compatible with the types of variables.
-Types much match or they must be coercable to the type.
+Types much match or they must be coercible to the type.
 
 Non-matching types fail, such as in the following example:
 
@@ -862,7 +862,7 @@ Non-matching types fail, such as in the following example:
   }
 ```
 
-However if a type is coerceable the query will pass validation.
+However if a type is coercible the query will pass validation.
 
 For example:
 
@@ -933,7 +933,7 @@ query VariableIsDefined($atOtherHomes: Boolean) {
 
 is valid. ${atOtherHomes} is defined by the operation.
 
-By constract the following query is invalid:
+By contrast the following query is invalid:
 
 ```!graphql
 query VariableIsNotDefined {
@@ -1194,4 +1194,4 @@ Query ListToNonNullList($booleanList: [Boolean]) {
 
 This would fail validation because a `[T]` cannot be passed to a `[T]!`.
 
-Similarily a `[T]` cannot be passed to a `[T!]`.
+Similarly a `[T]` cannot be passed to a `[T!]`.

Section 7 -- Response.md

@@ -6,7 +6,7 @@ operation if successful, and describes any errors encountered during the
 request.
 
 A response may contain both a partial response as well as encountered errors in
-the case that an error occured on a field which was replaced with null.
+the case that an error occurred on a field which was replaced with null.
 
 ## Serialization Format
 

Section 8 -- Grammar.md

@@ -73,7 +73,7 @@ Example_param :
 
 A GraphQL document is comprised of several kinds of source tokens defined here
 in a lexical grammar and used as terminal symbols in GraphQL's syntactic
-grammar. This lexical grammar defines patterns of source characters by specifing
+grammar. This lexical grammar defines patterns of source characters by specifying
 character patterns in {`monospace`} or as {/regular_expressions/}. Non-terminal
 patterns are defined as {Italics}.
 
@@ -131,8 +131,8 @@ Before every lexical token may be any amount of ignored source characters
 such as whitespace and comments. Whitespace, other than within strings, is
 not significant.
 
-GraphQL treats comma `,` similarly to whitespace. This ensures that the absense
-or presence of a comma does not meaningfully alter the interpretted syntax of
+GraphQL treats comma `,` similarly to whitespace. This ensures that the absence
+or presence of a comma does not meaningfully alter the interpreted syntax of
 the document which is a common user-error in other languages. It also allows for
 the stylistic use of trailing commas or line-breaks as delimiters which are
 often desired for legibility and maintainability of source code. The use of