Fix typos

doc/code.asciidoc

@@ -59,7 +59,7 @@ sections for their description.
 
 === Application `sw_core`
 
-.`priv/sw.schmea`
+.`priv/sw.schema`
 
 The schema definition file which can be read by the {project}
 system. It defines the schema rules for the Star Wars API.

doc/object_resolution.asciidoc

@@ -266,7 +266,7 @@ NOTE: An alternative implementation of the current object for
 Starships would be to return a `map()` which had all the relevant
 fields from the `#transport{}` and `#starship{}` rows merged. In
 short, it would be the same as if you had executed `SELECT * FROM
-Starship INNER JOIN Tranport USING (Id)`. It is worth examining if a
+Starship INNER JOIN Transport USING (Id)`. It is worth examining if a
 different representation will help in a given situation.
 
 ==== Id handling
@@ -469,7 +469,7 @@ return
 {ok, [{ok, A}, {error, Reason}, {ok, C}]}
 ----
 
-to signify that the two values `A` and `C` suceeded but `B` failed. If
+to signify that the two values `A` and `C` succeeded but `B` failed. If
 the data fetch fails as a whole you can of course fail the full field
 by returning `{error, Reason}`.
 
@@ -487,7 +487,7 @@ include::{sw_core}/src/sw_core_species.erl[tags=execute]
 ----
 
 Since the result can't fail, we wrap every result in an `{ok, EC}` to
-state that every eye colors loaded succesfully.
+state that every eye colors loaded successfully.
 
 .Alternative representation
 ****
@@ -631,7 +631,7 @@ and it won't cost bandwidth in data transfer.
 TIP: The example here describes a typical invocation: load the objects
 you operate on and make sure every object is valid. Then use
 <<authorization>> in the `_Ctx` to check if the desired operation is
-valid on the object. Next, execute a transaction and if succesful,
+valid on the object. Next, execute a transaction and if successful,
 return all the loaded objects in the *...Payload* result. This
 load-then-auth-then-txn invocation is very common in GraphQL.
 

doc/schema.asciidoc

@@ -203,7 +203,7 @@ result type of the given field is the return value of the mutation.
 This return type, often called the _payload_ contains other objects in
 the graph. It allows a client to run a mutation on the server side and
 then query on the data it just changed. This corresponds to the
-situtation in RESTful models where a POST provides a `location:`
+situation in RESTful models where a POST provides a `location:`
 response header containing the URI of the newly created object. But as
 we want to avoid a roundtrip, we "`bake`" the query into the mutation
 in GraphQL.

doc/system_tour.asciidoc

@@ -130,7 +130,7 @@ connections as we are here:
 include::{sw_test}/sw_SUITE_data/advanced.query[]
 ----
 
-The `fragment` parts allows your queries to re-use different subsets
+The `fragment` parts allows your queries to reuse different subsets
 of a larger query again and again. We use this here to show off that
 capability of GraphQL. The result follows the structure of the query:
 
@@ -174,7 +174,7 @@ include::{sw_test}/sw_SUITE_data/mutation.result[]
 ----
 <1> The server reflects back the unique client-generated Id for
 correlation purposes.
-<2> The Id migth be different depending on how many *Faction* objects
+<2> The Id might be different depending on how many *Faction* objects
     you created.
 <3> We have yet to assign any starships to the faction, so the count
     is currently 0.

doc/tricks.asciidoc

@@ -168,7 +168,7 @@ TBD
 TBD
 
 [[lazy-evaluation]]
-=== Lazy Evalution
+=== Lazy Evaluation
 
 If you have data where computation is circular, you will have to make
 sure you don't build an infinite loop in the data. This system has