enter review comments

Kevin Harper · Kevin Harper · commit 9dd5d40cb216 · 2018-04-13T10:27:50.000-05:00
diff --git a/guides/v2.3/graphql/develop/create-graphqls-file.md b/guides/v2.3/graphql/develop/create-graphqls-file.md
@@ -6,7 +6,7 @@ title: Define the GraphQL schema for a module
 github_link: graphql/develop/create-graphqls-file.md
 ---
 
-Each module that adds to or extends from a GraphQL schema can do so by placing a `schema.graphqls` file in its `etc` directory. Magento Core adds GraphQL modules based on the purpose of the schema being extended/added, and what core modules they depend on. For example, the CustomerGraphQl adds a query to the graphql endpoint to view customer data, and relies on the Customer core module
+Each module that adds to or extends from a GraphQL schema can do so by placing a `schema.graphqls` file in its `etc` directory. Magento Core adds GraphQl modules based on the purpose of the schema being extended/added and the core modules they depend on. For example, the CustomerGraphQl module adds a query to the graphql endpoint to view customer data and relies on the Customer core module.
 
 A GraphQL module's `schema.graphqls` file defines how the attributes defined in the module can be used in a GraphQL query. If your module's attributes are completely self-contained, then the `schema.graphqls` file defines the query, the interfaces used, the data types of all the attributes, and any enumerations that restrict the possible attribute contents. If your module simply extends another module (such as Catalog), then you must define those attributes and ensure that the other module can load your attributes.
 
@@ -17,15 +17,15 @@ The `<module_name>/etc/schema.graphqls` file:
 * Points to the resolvers that verify and process the query data and response
 * Serves as the source for displaying the schema in a GraphQL browser
 
-The base `schema.graphqls` file, located in the `app/code/GraphQl/etc/` directory, provides the basic structure for all GraphQL queries, including definitions for comparison operators and paging information for search results. The `webonyx/graphql-php` library enforces the syntax of all `schema.graphqls` files.
+The base `schema.graphqls` file, located in the `app/code/GraphQl/etc/` directory, provides the necessary structure for all GraphQL queries, including definitions for comparison operators and paging information for search results. The `webonyx/graphql-php` library enforces the syntax of all `schema.graphqls` files.
 
 To illustrate how to configure the `schema.graphqls` file, let's suppose you have a module named Volumizer that calculates the volume of a product, given its height, width, and depth. We'll assume this module extends the Catalog module.
 
 ## Define the query
 
 A query definition can be one line, or it can be complex. If your module's query implements `searchCriteria`, then you must define arguments that define filters and pagination information, all of which adds complexity. However, if you expect a single result from your query, then its definition can be simple.
 
-The following example shows the `products` query. The `type` is defined as a `Query`.  The `products` definitions define the keywords that are used to construct a query, as shown in [Searches and pagination in GraphQL]({{page.baseurl}}graphql/search-pagination.html). The parameter definitions will be discussed in [Specify output attributes](#specify-output-attributes)
+The following example shows the `products` query. The `type` is defined as a `Query`.  The `products` definitions define the keywords that are used to construct a query, as shown in [Searches and pagination in GraphQL]({{page.baseurl}}graphql/search-pagination.html). The parameter definitions will be discussed in [Specify output attributes](#specify-output-attributes).
 
 ``` php
 type Query {
@@ -51,7 +51,7 @@ If all your module's attributes are extension attributes for existing modules, t
 
 ## Declare input attributes
 
-You must explicitly define each attribute that can be used as input in a GraphQL query. In the simplest cases, you can create a single `type` defintion that includes all the input, output, and sorting attributes for an object. This might not be possible if your module performs calculations, or otherwise has attributes that aren't available at the time of the query.
+You must explicitly define each attribute that can be used as input in a GraphQL query. In the simplest cases, you can create a single `type` definition that includes all the input, output, and sorting attributes for an object. This might not be possible if your module performs calculations, or otherwise has attributes that aren't available at the time of the query.
 
 The theoretical Volumizer module extends `Catalog`. In this case, you would reference `ProductFilterInput` as the source and make each attribute be of type `FilterTypeInput`. (Both of these entities are defined in `CatalogGraphQl`'s `schema.graphqls` file. In other use cases, you would be required to create your own input type.
 
@@ -67,7 +67,7 @@ input ProductFilterInput {
 
 ## Specify sorting attributes
 
-You can also define which attributes can be used for sorting the search results. This list does not not have to be identical to the list of input or output attributes.
+You can also define which attributes can be used for sorting the search results. This list does not have to be identical to the list of input or output attributes.
 
 This example allows sorting on the `v_volume` attribute only.
 
@@ -85,11 +85,11 @@ input ProductSortInput {
 
 You must know the data type of each attribute, whether it is scalar or an object, and whether it can be part of an array. In addition, each attribute within an object must be defined in the same manner.
 
-In an `schema.graphqls` file, the output `Interface` defines top-level attributes. Each object returned is defined in a `type` definition.
+In a `schema.graphqls` file, the output `Interface` defines top-level attributes. Each object returned is defined in a `type` definition.
 
 ### Define the output interface
 
-In many cases, the response contains data that was either not available as input, or it was transformed in some manner from the input. For example, when you specify a price in an input filter, Magento evaluates it as a Float value. However, `Price` output objects contain a Float value, a currency value, and possibly minimum/maximum values and tax adjustments. You can define a `typeResolver` to point to the Resolver object, which interprets the GraphQL query. If your module contains only attributes that extend another module, then this parameter is optional. Otherwise, it is required. See [Resolvers]({{page.baseurl}}graphql/resolvers.html) for more information.
+In many cases, the response contains data that was either not available as input, or was transformed in some manner from the input. For example, when you specify a price in an input filter, Magento evaluates it as a Float value. However, `Price` output objects contain a Float value, a currency value, and possibly minimum/maximum values and tax adjustments. You can define a `typeResolver` to point to the Resolver object, which interprets the GraphQL query. If your module contains only attributes that extend another module, then this parameter is optional. Otherwise, it is required. See [Resolvers]({{page.baseurl}}graphql/resolvers.html) for more information.
 
 The following example defines module-specific output attributes for the Volumizer module.
 
@@ -130,7 +130,7 @@ enum VolumeUnitEnum {
 
 ## Annotations
 
-You can provide a description of any attribute, type definition, or other entity within a `schema.graphqls` file by appending the following to the line:
+You can describe any attribute, type definition, or other entity within a `schema.graphqls` file by appending the following to the line:
 
 `@doc(description: "<Text>")`
 
diff --git a/guides/v2.3/graphql/index.md b/guides/v2.3/graphql/index.md
@@ -18,8 +18,8 @@ Most of the development team's work thus far has been devoted to building the Gr
 GraphQL allows you to define the structure of the data that you need, and the server returns only the data you request. Each GraphQL-capable module contains a declarative schema that defines the syntax for queries that the module supports, as well as the attributes that can be returned. If you run a REST call such as `GET /V1/products/:sku` on a simple product, the system might fetch more than 100 lines of data. If all you need is the current price, the call has returned significantly more information than you need. With GraphQL, a query against the same SKU could return just the price.
 
 A GraphQL-enabled module handles externally-defined attributes differently than other Magento modules. We used the following techniques to manage product-related attributes, but you are free to use alternate methods:
-`
-* **EAV attributes** are explicitly declared in the `schema.graphqls files.
+
+* **EAV attributes** are explicitly declared in the `schema.graphqls` files.
 * **Custom attributes** are treated as dynamic attributes that might or might not be present. Therefore, they are not declared in the schema. Instead, we've implemented a reader that queries the database and gets any declared custom attributes. These attributes can be declared in the schema if you know they'll always be present.
 * **Extension attributes** can be declared in a `schema.graphqls` file or by a custom reader, but they should be declared in a separate `*GraphQl` module. The attributes should extend from the resolver that fetches that model's data.
 
