fix mismatched quotes pairs

Author: ma2gedev

content/documentation/master/data-fetching.md

@@ -183,7 +183,7 @@ the query is executed.  The following section explains more on this.
 * ``DataFetchingFieldSelectionSet getSelectionSet()`` - the selection set represents the child fields that have been "selected" under neath the
 currently executing field. This can be useful to help look ahead to see what sub field information a client wants.  The following section explains more on this.
 
-* ```ExecutionId getExecutionId()`` - each query execution is given a unique id.  You can use this perhaps on logs to tag each individual
+* ``ExecutionId getExecutionId()`` - each query execution is given a unique id.  You can use this perhaps on logs to tag each individual
 query.
 
 

content/documentation/master/exceptions.md

@@ -28,7 +28,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
 
  -  `graphql.execution.UnresolvedTypeException`
 
- is thrown if a  graphql.schema.TypeResolver` fails to provide a concrete
+ is thrown if a `graphql.schema.TypeResolver` fails to provide a concrete
  object type given a interface or union type.
 
 
@@ -47,7 +47,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
  -  `graphql.schema.validation.InvalidSchemaException`
 
  is thrown if the schema is not valid when built via
-  graphql.schema.GraphQLSchema.Builder#build()`
+  `graphql.schema.GraphQLSchema.Builder#build()`
 
  -  `graphql.execution.UnknownOperationException`
 

content/documentation/master/execution.md

@@ -419,7 +419,7 @@ By default the "query" execution strategy is ``graphql.execution.AsyncExecutionS
 each field as ``CompleteableFuture`` objects and not care which ones complete first.  This strategy allows for the most
 performant execution.
 
-The data fetchers invoked can themselves return `CompletionStage`` values and this will create
+The data fetchers invoked can themselves return ``CompletionStage`` values and this will create
 fully asynchronous behaviour.
 
 So imagine a query as follows

content/documentation/master/scalars.md

@@ -69,12 +69,12 @@ We would create a singleton ``graphql.schema.GraphQLScalarType`` instance for th
 The real work in any custom scalar implementation is the ``graphql.schema.Coercing`` implementation.  This is responsible for 3 functions
 
 * ``parseValue`` - takes a variable input object and converts into the Java runtime representation
-* ``parseLiteral`` - takes an AST literal ``graphql.language.Value` as input and converts into the Java runtime representation
+* ``parseLiteral`` - takes an AST literal ``graphql.language.Value`` as input and converts into the Java runtime representation
 * ``serialize`` - takes a Java object and converts it into the output shape for that scalar
 
 So your custom scalar code has to handle 2 forms of input (parseValue / parseLiteral)  and 1 form of output (serialize).
 
-Imagine this query, which uses variables, AST literals and outputs our scalar type ```email``.
+Imagine this query, which uses variables, AST literals and outputs our scalar type ``email``.
 
 {{< highlight graphql "linenos=table" >}}
     mutation Contact($mainContact: Email!) {

content/documentation/v10/data-fetching.md

@@ -183,7 +183,7 @@ the query is executed.  The following section explains more on this.
 * ``DataFetchingFieldSelectionSet getSelectionSet()`` - the selection set represents the child fields that have been "selected" under neath the
 currently executing field. This can be useful to help look ahead to see what sub field information a client wants.  The following section explains more on this.
 
-* ```ExecutionId getExecutionId()`` - each query execution is given a unique id.  You can use this perhaps on logs to tag each individual
+* ``ExecutionId getExecutionId()`` - each query execution is given a unique id.  You can use this perhaps on logs to tag each individual
 query.
 
 

content/documentation/v10/exceptions.md

@@ -28,7 +28,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
 
  -  `graphql.execution.UnresolvedTypeException`
 
- is thrown if a  graphql.schema.TypeResolver` fails to provide a concrete
+ is thrown if a `graphql.schema.TypeResolver` fails to provide a concrete
  object type given a interface or union type.
 
 
@@ -47,7 +47,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
  -  `graphql.schema.validation.InvalidSchemaException`
 
  is thrown if the schema is not valid when built via
-  graphql.schema.GraphQLSchema.Builder#build()`
+  `graphql.schema.GraphQLSchema.Builder#build()`
 
  -  `graphql.execution.UnknownOperationException`
 

content/documentation/v10/execution.md

@@ -419,7 +419,7 @@ By default the "query" execution strategy is ``graphql.execution.AsyncExecutionS
 each field as ``CompleteableFuture`` objects and not care which ones complete first.  This strategy allows for the most
 performant execution.
 
-The data fetchers invoked can themselves return `CompletionStage`` values and this will create
+The data fetchers invoked can themselves return ``CompletionStage`` values and this will create
 fully asynchronous behaviour.
 
 So imagine a query as follows

content/documentation/v10/scalars.md

@@ -69,12 +69,12 @@ We would create a singleton ``graphql.schema.GraphQLScalarType`` instance for th
 The real work in any custom scalar implementation is the ``graphql.schema.Coercing`` implementation.  This is responsible for 3 functions
 
 * ``parseValue`` - takes a variable input object and converts into the Java runtime representation
-* ``parseLiteral`` - takes an AST literal ``graphql.language.Value` as input and converts into the Java runtime representation
+* ``parseLiteral`` - takes an AST literal ``graphql.language.Value`` as input and converts into the Java runtime representation
 * ``serialize`` - takes a Java object and converts it into the output shape for that scalar
 
 So your custom scalar code has to handle 2 forms of input (parseValue / parseLiteral)  and 1 form of output (serialize).
 
-Imagine this query, which uses variables, AST literals and outputs our scalar type ```email``.
+Imagine this query, which uses variables, AST literals and outputs our scalar type ``email``.
 
 {{< highlight graphql "linenos=table" >}}
     mutation Contact($mainContact: Email!) {

content/documentation/v11/data-fetching.md

@@ -183,7 +183,7 @@ the query is executed.  The following section explains more on this.
 * ``DataFetchingFieldSelectionSet getSelectionSet()`` - the selection set represents the child fields that have been "selected" under neath the
 currently executing field. This can be useful to help look ahead to see what sub field information a client wants.  The following section explains more on this.
 
-* ```ExecutionId getExecutionId()`` - each query execution is given a unique id.  You can use this perhaps on logs to tag each individual
+* ``ExecutionId getExecutionId()`` - each query execution is given a unique id.  You can use this perhaps on logs to tag each individual
 query.
 
 

content/documentation/v11/exceptions.md

@@ -28,7 +28,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
 
  -  `graphql.execution.UnresolvedTypeException`
 
- is thrown if a  graphql.schema.TypeResolver` fails to provide a concrete
+ is thrown if a `graphql.schema.TypeResolver` fails to provide a concrete
  object type given a interface or union type.
 
 
@@ -47,7 +47,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
  -  `graphql.schema.validation.InvalidSchemaException`
 
  is thrown if the schema is not valid when built via
-  graphql.schema.GraphQLSchema.Builder#build()`
+  `graphql.schema.GraphQLSchema.Builder#build()`
 
  -  `graphql.execution.UnknownOperationException`