More fixes in spelling/grammar

Author: bkoelman

docs/usage/common-pitfalls.md

@@ -73,13 +73,13 @@ the richness of JSON:API. For example, it enables users to include related resou
 As an API developer, you'll benefit from rich input validation and fine-grained control for setting what's permitted when users access relationships.
 
 #### Model relationships instead of complex (JSON) attributes
-Similar to the above, returning a complex object takes away all the relationship features of JSON:API. Users can't filter inside a complex object. Or update
-a nested value, without risking accidentally overwriting another unrelated nested value from a concurrent request. Basically, there's no partial PATCH to prevent that.
+Similar to the above, returning a complex object takes away all the relationship features of JSON:API. Users can't filter inside a complex object, nor update
+a nested value without risking accidentally overwriting another unrelated nested value from a concurrent request because there's no partial PATCH to prevent that.
 
 #### Stay away from stored procedures
 There are [many reasons](https://stackoverflow.com/questions/1761601/is-the-usage-of-stored-procedures-a-bad-practice/9483781#9483781) to not use stored procedures.
 But with JSON:API, there's an additional concern. Due to its dynamic nature of filtering, sorting, pagination, sparse fieldsets, and including related resources,
-the number of required stored procedures to support all that either explodes, or you'll end up with one extremely complex stored proceduce to handle it all.
+the number of required stored procedures to support all that either explodes, or you'll end up with one extremely complex stored procedure to handle it all.
 With stored procedures, you're either going to have a lot of work to do, or you'll end up with an API that has very limited capabilities.
 Neither sounds very compelling. If stored procedures is what you need, you're better off creating an RPC-style API that doesn't use JsonApiDotNetCore.
 

docs/usage/errors.md

@@ -2,7 +2,7 @@
 
 Errors returned will contain only the properties that are set on the `ErrorObject` class. Custom fields can be added through `ErrorObject.Meta`.
 You can create a custom error by throwing a `JsonApiException` (which accepts an `ErrorObject` instance), or returning an `ErrorObject` instance from an `ActionResult` in a controller.
-Please keep in mind that JSON:API requires `Title` to be a generic message, while `Detail` should contain information about the specific problem occurence.
+Please keep in mind that JSON:API requires `Title` to be a generic message, while `Detail` should contain information about the specific problem occurrence.
 
 From a controller method:
 

docs/usage/extensibility/query-strings.md

@@ -21,7 +21,7 @@ See [here](~/usage/extensibility/resource-definitions.md#custom-query-string-par
 
 ## Custom query string parsing
 
-In order to add parsing of custom query string parameters, you can implement the `IQueryStringParameterReader` interface and register your reader.
+To add parsing of custom query string parameters, implement the `IQueryStringParameterReader` interface and register your reader.
 
 ```c#
 public class CustomQueryStringParameterReader : IQueryStringParameterReader

docs/usage/extensibility/services.md

@@ -111,7 +111,7 @@ IResourceCommandService <|-- ISetRelationshipService
 IResourceCommandService <|-- IRemoveFromRelationshipService
 ```
 
-In order to take advantage of these interfaces you first need to register the service for each implemented interface.
+To take advantage of these interfaces, register the service for each implemented interface.
 
 ```c#
 public class ArticleService : ICreateService<Article, long>, IDeleteService<Article, long>

docs/usage/resources/nullability.md

@@ -60,7 +60,7 @@ public sealed class Label : Identifiable<long>
 
 When NRT is turned on, use nullability annotations (?) on attributes and relationships. This makes Entity Framework Core generate non-nullable columns. And model errors are returned when non-nullable fields are omitted.
 
-The [Entity Framework Core guide on NRT](https://learn.microsoft.com/ef/core/miscellaneous/nullable-reference-types) recommends to use constructor binding to initialize non-nullable properties, but JsonApiDotNetCore does not support that. For required navigation properties, it suggests to use a non-nullable property with a nullable backing field. JsonApiDotNetCore does not support that either. In both cases, just use the null-forgiving operator (!).
+The [Entity Framework Core guide on NRT](https://learn.microsoft.com/ef/core/miscellaneous/nullable-reference-types) recommends using constructor binding to initialize non-nullable properties, but JsonApiDotNetCore does not support that. For required navigation properties, it suggests using a non-nullable property with a nullable backing field. JsonApiDotNetCore does not support that either. In both cases, use the null-forgiving operator (!).
 
 When ModelState validation is turned on, to-many relationships must be assigned an empty collection. Otherwise an error is returned when they don't occur in the request body.
 

src/Examples/DapperExample/FromEntitiesNavigationResolver.cs

@@ -32,7 +32,7 @@ public FromEntitiesNavigationResolver(IResourceGraph resourceGraph, FromEntities
 
     public void Resolve()
     {
-        // In order to produce SQL, some knowledge of the underlying database model is required.
+        // To produce SQL, some knowledge of the underlying database model is required.
         // Because the database in this example project is created using Entity Framework Core, we derive that information from its model.
         // Some alternative approaches to consider:
         // - Query the database to obtain model information at startup.

src/JsonApiDotNetCore/Middleware/IAsyncConvertEmptyActionResultFilter.cs

@@ -7,16 +7,16 @@ namespace JsonApiDotNetCore.Middleware;
 /// Converts action result without parameters into action result with null parameter.
 /// </summary>
 /// <remarks>
-/// This basically turns calls such as
+/// This converts calls such as:
 /// <c>
 /// return NotFound()
 /// </c>
-/// into
+/// into:
 /// <c>
 /// return NotFound(null)
 /// </c>
 /// , so that our formatter is invoked, where we'll build a JSON:API compliant response. For details, see:
-/// https://github.com/dotnet/aspnetcore/issues/16969
+/// https://github.com/dotnet/aspnetcore/issues/16969.
 /// </remarks>
 [PublicAPI]
 public interface IAsyncConvertEmptyActionResultFilter : IAsyncAlwaysRunResultFilter;