Minor fixes to type system chapter

Author: lorensr

text/type-system/directives.md

@@ -5,7 +5,7 @@ description: Schema directives define the directives that can be used in query d
 
 # Directives
 
-We talked about the query side of [directives](http://spec.graphql.org/draft/#sec-Type-System.Directives) in [Chapter 2: Directives](../query-language/directives.md). Directives are declared in the schema. A directive definition includes its name, any arguments, on what types of locations it can be used, and whether it’s repeatable (used multiple times on the same location):
+We talked about the query side of [directives](http://spec.graphql.org/draft/#sec-Type-System.Directives) in [Chapter 2: Directives](../query-language/directives.md). Directives are declared in the schema. A directive definition includes its name, any arguments, on what types of locations it can be used, and whether it’s repeatable (can be used multiple times in the same location):
 
 ```gql
 directive @authoredBy(name: String!) repeatable on OBJECT

text/type-system/extending.md

@@ -13,7 +13,6 @@ type Query {
 }
 
 type Direction {
-  NORTHWEST @deprecated
   NORTH
   EAST
   SOUTH

text/type-system/field-arguments.md

@@ -5,7 +5,7 @@ description: Arguments can be added to any field in the schema
 
 # Field arguments
 
-Any field can accept a named, unordered list of [arguments]. Arguments can be scalars, enums, or *input objects*. An argument can be non-null to indicate it is required. Optional arguments can have a default value, like `name` below.
+Any field can accept a named, unordered list of [arguments](http://spec.graphql.org/draft/#sec-Field-Arguments). Arguments can be scalars, enums, or *input objects*. An argument can be non-null to indicate it is required. Optional arguments can have a default value, like `name` below.
 
 ```gql
 type User {

text/type-system/interfaces.md

@@ -55,7 +55,7 @@ type User {
 }
 ```
 
-We can now query for fields in `BankAccount`
+We can now query for fields in `BankAccount`:
 
 ```gql
 query {

text/type-system/objects.md

@@ -19,17 +19,17 @@ type User {
 }
 ```
 
-A field’s type can be anything but an input object. In the `Post` type, the `id` and `text` fields are scalars, while `author` is an object type. 
+A field’s type can be any type but an input object. In the `Post` type, the `id` and `text` fields are scalars, while `author` is an object type. 
 
-When selecting a field that has an object type, at least one of that object’s fields must be selected. For instance, in the below schema, `post` field is of type `Post`:
+When selecting a field that has an object type, at least one of that object’s fields must be selected. For instance, in the below schema, the `post` field is of type `Post`:
 
 ```gql
 type Query {
   post(id: ID): Post
 }
 ```
 
-Since `Post` is an object type, at least one `Post` field must be selected in query A below—in this case, `text`. And in query B, `post.author` is of type `User`, so at least one `User` field must be selected.
+Since `Post` is an object type, at least one `Post` field must be selected in query A below—in this case, `text` is selected. And in query B, `post.author` is of type `User`, so at least one `User` field must be selected.
 
 ```gql
 query A {

text/type-system/scalars.md

@@ -15,12 +15,15 @@ title: Scalars
 We can also define our own scalars, like `Url` and `DateTime`. In the description of our custom scalars, we write how they’re serialized so the frontend developer knows what value to provide for arguments. For instance, `DateTime` could be serialized as an integer (milliseconds since [Epoch](https://en.wikipedia.org/wiki/Epoch_(computing))) or as an ISO string:
 
 ```gql
-# schema
+scalar DateTime
+
 type Mutation {
   dayOfTheWeek(when: DateTime): String
 }
 ```
 
+Given the above schema, the client would send one of the below operations, depending on the definition of `DateTime`:
+
 ```gql
 # if DateTime is serialized as an integer
 mutation {
@@ -33,6 +36,6 @@ mutation {
 }
 ```
 
-The benefits to using custom scalars are clarity (`when: DateTime` is clearer than `when: Int`) and consistent validation (whatever value we pass is checked to make sure it’s a valid DateTime).
+The benefits to using custom scalars are clarity (`when: DateTime` is clearer than `when: Int`) and consistent validation (whatever value we pass is checked to make sure it’s a valid `DateTime`).
 
 We define our [own custom scalar](../server/building/custom-scalars.md) in Chapter 11.

text/type-system/schema.md

@@ -42,5 +42,5 @@ and receive this response:
 }
 ```
 
-The root fields—those listed under `type Query { ... }`, `type Mutation { ... }`, and `type Subscription { ... }` are the entry points to our schema—the fields that can be selected by the client at the root level of an operation.
+The root fields—those listed under `type Query { ... }`, `type Mutation { ... }`, and `type Subscription { ... }`—are the entry points to our schema. They’re the fields that can be selected by the client at the root level of an operation.
 

text/type-system/types.md

@@ -21,5 +21,5 @@ The two wrapping types are:
 - [List](lists.md)
 - [Non-null](non-null.md)
 
-When the named types appear by themselves, they are singular and nullable—i.e., when the client requests a field, the server will return either one item or `null`. These two wrapping types change this default behavior.
+When the named types appear by themselves, they are singular and nullable—i.e., when the client requests a field, the server will return either one item or `null`. Using a wrapping type changes this default behavior.
 

text/type-system/unions.md

@@ -41,5 +41,5 @@ query {
 }
 ```
 
-Since unions don’t guarantee any fields in common, any field we select has to be inside a fragment (which have a specific object type).
+Since unions don’t guarantee any fields in common, any field we select has to be inside a fragment (which has a specific object type).