edit pass: azure-functions-triggers-and-bindings

Author: ShawnJackson

articles/azure-functions/extension-bundles.md

@@ -27,7 +27,7 @@ You define an extension bundle reference in the `host.json` project file by addi
 
 ## Supported extension bundles
 
-This table lists all `Microsoft.Azure.Functions.ExtensionBundle` bundle versions and the current [support state](#support-policy).
+This table lists all `Microsoft.Azure.Functions.ExtensionBundle` bundle versions and the current [support state](#support-policy):
 
 | Bundle version | Version in host.json | Support state | End-of-support date |
 | --- | --- | --- | --- |
@@ -44,11 +44,11 @@ Keep these considerations in mind when you work with extension bundles:
 
 - When possible, you should set a `version` range value in `host.json` from the preceding table, such as `[4.0.0, 5.0.0)`, instead of defining a custom range.
 - Use the latest version range to obtain optimal app performance and access to the latest features.
-- In the unlikely event that you can't use an extension bundle, you must instead [explicitly install extensions](./functions-bindings-register.md#explicitly-installing-extensions).
+- In the unlikely event that you can't use an extension bundle, you must instead [explicitly install extensions](./functions-bindings-register.md#explicitly-install-extensions).
 
 ## Previewing extension bundles
 
-Prerelease versions of specific binding extensions are maintained in a preview extension bundle. The preview extension bundle (`Microsoft.Azure.Functions.ExtensionBundle.Preview`) allows you to take advantage of preview extensions and new behaviors in existing extensions before they reach general availability (GA).
+Prerelease versions of specific binding extensions are maintained in a preview extension bundle: `Microsoft.Azure.Functions.ExtensionBundle.Preview`. You can use this preview extension bundle to take advantage of preview extensions and new behaviors in existing extensions before they reach general availability (GA).
 
 Keep these considerations in mind when you choose to use a non-GA extension bundle:
 
@@ -62,10 +62,10 @@ Keep these considerations in mind when you choose to use a non-GA extension bund
   - Pin your bundle to a specific, well-tested bundle version instead of to a range. Pinning prevents automatic upgrading of your bundle version before you have a chance to verify the update in a nonproduction environment.
   - Move your app to using a GA bundle version as soon as the functionality becomes available in a fully supported bundle release.
 - To stay informed about bundle updates, including moving from preview to GA, you should:
-  - Monitor preview bundle version releases on the [release page for extension bundles](https://github.com/Azure/azure-functions-extension-bundles/releases).
+  - Monitor releases of preview bundle versions on the [release page for extension bundles](https://github.com/Azure/azure-functions-extension-bundles/releases).
   - Monitor [extension-specific reference documentation](./functions-triggers-bindings.md).
   - Review the NuGet package versions of specific preview extensions that you're using.
-  - Track significant updates or changes on the change logs published on NuGet.org for each preview extension.
+  - Track significant updates or changes in the change logs published on NuGet.org for each preview extension.
 
 ## Support policy
 

articles/azure-functions/functions-bindings-error-pages.md

@@ -39,7 +39,7 @@ To avoid loss of data or missed messages, you should practice good error handlin
 
 ## Retries
 
-There are two kinds of retries available for your functions:
+Two kinds of retries are available for your functions:
 
 - Built-in retry behaviors of individual trigger extensions
 - Retry policies that the Azure Functions runtime provides
@@ -62,7 +62,7 @@ The following table indicates which triggers support retries and where the retry
 
 ## Retry policies
 
-With Azure Functions, you can define retry policies for specific trigger types. The runtime enforces these retry policies. These trigger types currently support retry policies:
+With Azure Functions, you can define retry policies for specific trigger types. The runtime enforces these retry policies. The following trigger types currently support retry policies:
 
 - [Azure Cosmos DB](./functions-bindings-cosmosdb-v2-trigger.md)
 - [Event Hubs](./functions-bindings-event-hubs-trigger.md)
@@ -205,7 +205,7 @@ You can set these properties on retry policy definitions:
 ::: zone-end  
 
 ::: zone pivot="programming-language-javascript"
-The way you define the retry policy for the trigger depends on your Node.js version:
+The way that you define the retry policy for the trigger depends on your Node.js version:
 
 #### [Node.js v4](#tab/node-v4)
 
@@ -224,7 +224,7 @@ Here's an example of a fixed-delay retry policy defined in the `function.json` f
 ::: zone-end
 
 ::: zone pivot="programming-language-typescript"  
-The way you define the retry policy for the trigger depends on your Node.js version.
+The way that you define the retry policy for the trigger depends on your Node.js version:
 
 #### [Node.js v4](#tab/node-v4)
 

articles/azure-functions/functions-bindings-expressions-patterns.md

@@ -14,7 +14,7 @@ One of the most powerful features of [triggers and bindings](./functions-trigger
 
 Most expressions are wrapped in curly braces. For example, in a queue trigger function, `{queueTrigger}` resolves to the queue message text. If the `path` property for a blob output binding is `container/{queueTrigger}` and a queue message `HelloWorld` triggers the function, a blob named `HelloWorld` is created.
 
-<a name = binding-expressions---app-settings></a>## App settings
+## <a name = binding-expressions---app-settings></a>App settings
 
 It's a best practice to manage secrets and connection strings by using app settings rather than configuration files. This practice limits access to these secrets and makes it safe to store files such as `function.json` in public source-control repositories.
 

articles/azure-functions/functions-bindings-register.md

@@ -31,7 +31,7 @@ In the unlikely event that you can't use an extension bundle, you must instead e
 
 ::: zone-end
 
-<a name = "explicitly-install-extensions"></a>## Explicitly installing extensions
+## <a name = "explicitly-install-extensions"></a>Explicitly installing extensions
 ::: zone pivot="programming-language-csharp"  
 For projects that use a compiled C# class library, you install the NuGet packages for the extensions that you need as you normally would in your apps. For more information, see the [Visual Studio Code developer guide](functions-develop-vs-code.md?tabs=csharp#install-binding-extensions) or the [Visual Studio developer guide](functions-develop-vs.md#add-bindings).