Fix minor typos in MarkDown

content/documentation/master/sdl-directives.md

@@ -128,7 +128,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v10/batching.md

@@ -99,7 +99,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }
@@ -137,7 +137,7 @@ Here is how you might put this in place:
 
         //
         // this instrumentation implementation will dispatch all the dataloaders
-        // as each level fo the graphql query is executed and hence make batched objects
+        // as each level for the graphql query is executed and hence make batched objects
         // available to the query and the associated DataFetchers
         //
         DataLoaderDispatcherInstrumentation dispatcherInstrumentation
@@ -155,7 +155,7 @@ Here is how you might put this in place:
 {{< / highlight >}}
 
 One thing to note is the above only works if you use `DataLoaderDispatcherInstrumentation` which makes sure `dataLoader.dispatch()`
-is called.  If this was not in place, then all the promises to data will never be dispatched ot the batch loader function
+is called.  If this was not in place, then all the promises to data will never be dispatched to the batch loader function
 and hence nothing would ever resolve.
 
 ## Data Loader only works with AsyncExecutionStrategy

content/documentation/v10/sdl-directives.md

@@ -124,7 +124,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v11/batching.md

@@ -101,7 +101,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }

content/documentation/v11/sdl-directives.md

@@ -124,7 +124,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v12/batching.md

@@ -102,7 +102,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }

content/documentation/v12/sdl-directives.md

@@ -128,7 +128,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v13/batching.md

@@ -102,7 +102,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }

content/documentation/v13/sdl-directives.md

@@ -128,7 +128,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v14/batching.md

@@ -102,7 +102,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }

content/documentation/v14/sdl-directives.md

@@ -128,7 +128,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v15/batching.md

@@ -102,7 +102,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }

content/documentation/v15/sdl-directives.md

@@ -128,7 +128,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the

content/documentation/v9/batching.md

@@ -99,7 +99,7 @@ Here is how you might put this in place:
             @Override
             public CompletionStage<List<Object>> load(List<String> keys) {
                 //
-                // we use supplyAsync() of values here for maximum parellisation
+                // we use supplyAsync() of values here for maximum parallelisation
                 //
                 return CompletableFuture.supplyAsync(() -> getCharacterDataViaBatchHTTPApi(keys));
             }
@@ -137,7 +137,7 @@ Here is how you might put this in place:
 
         //
         // this instrumentation implementation will dispatch all the dataloaders
-        // as each level fo the graphql query is executed and hence make batched objects
+        // as each level for the graphql query is executed and hence make batched objects
         // available to the query and the associated DataFetchers
         //
         DataLoaderDispatcherInstrumentation dispatcherInstrumentation
@@ -155,7 +155,7 @@ Here is how you might put this in place:
 {{< / highlight >}}
 
 One thing to note is the above only works if you use `DataLoaderDispatcherInstrumentation` which makes sure `dataLoader.dispatch()`
-is called.  If this was not in place, then all the promises to data will never be dispatched ot the batch loader function
+is called.  If this was not in place, then all the promises to data will never be dispatched to the batch loader function
 and hence nothing would ever resolve.
 
 ## Data Loader only works with AsyncExecutionStrategy

content/documentation/v9/sdl-directives.md

@@ -124,7 +124,7 @@ We now need to wire in the code that can handle any field with this ``@auth`` di
 {{< / highlight >}}
 
 This has modified the ``GraphQLFieldDefinition`` so that its original data fetcher will ONLY be called if the current authorisation context
-has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesnt
+has the ``manager`` role.  Exactly what mechanisms you use for authorisation is up to you.  You could use Spring Security for example say, graphql-java doesn't
 really care.
 
 You would provide this authorisation checker into the execution "context" object of the graphql input so it can then be accessed later in the