integrating review feedback

Author: v-gweinstock

articles/digital-twins/concepts-cli.md

@@ -28,7 +28,7 @@ Some of the actions you can do using the command set include:
 * Managing [routes](concepts-route-events.md)
 * Configuring [security](concepts-security.md) via Azure role-based access control (Azure RBAC)
 
-The command set is called *az dt*, and is part of the [Azure IoT extension for Azure CLI](https://github.com/Azure/azure-iot-cli-extension). You can view the full list of commands and their usage as part of the reference documentation for the `az iot` command set: [az dt command reference](/cli/azure/dt).
+The command set is called `az dt`, and is part of the [Azure IoT extension for Azure CLI](https://github.com/Azure/azure-iot-cli-extension). You can view the full list of commands and their usage as part of the reference documentation for the `az iot` command set: [az dt command reference](/cli/azure/dt).
 
 ## Uses (deploy and validate)
 

articles/digital-twins/concepts-data-ingress-egress.md

@@ -46,7 +46,7 @@ There are many other services where you may want to ultimately direct your data,
 
 For example, if you're also using Azure Maps and want to correlate location with your Azure Digital Twins graph, you can use Azure Functions with Event Grid to establish communication between all the services in your deployment. For more information on integrating Azure Maps, see [Use Azure Digital Twins to update an Azure Maps indoor map](how-to-integrate-maps.md). For information on routing data in a similar way to Time Series Insights, see [Integrate with Time Series Insights](how-to-integrate-time-series-insights.md).
 
-Azure Digital Twins implements "at least once" delivery for data emitted to egress services. 
+Azure Digital Twins implements *at least once* delivery for data emitted to egress services. 
 
 ## Next steps
 

articles/digital-twins/concepts-models.md

@@ -42,7 +42,7 @@ Not all services that use DTDL implement the exact same features of DTDL. There
 
 For a DTDL model to be compatible with Azure Digital Twins, it must also meet these requirements:
 
-* All top-level DTDL elements in a model must be of type interface. The reason for this requirement is that Azure Digital Twins model APIs can receive JSON objects that represent either an interface or an array of interfaces. As a result, no other DTDL element types are allowed at the top level.
+* All top-level DTDL elements in a model must be of type `Interface`. The reason for this requirement is that Azure Digital Twins model APIs can receive JSON objects that represent either an interface or an array of interfaces. As a result, no other DTDL element types are allowed at the top level.
 * DTDL for Azure Digital Twins must not define any commands.
 * Azure Digital Twins only allows a single level of component nesting, meaning that an interface that's being used as a component can't have any components itself. 
 * Interfaces can't be defined inline within other DTDL interfaces; they must be defined as separate top-level entities with their own IDs. Then, when another interface wants to include that interface as a component or through inheritance, it can reference its ID.
@@ -82,7 +82,7 @@ The fields of the model are:
 | `@type` | Identifies the kind of information being described. For an interface, the type is `Interface`. |
 | `@context` | Sets the [context](https://niem.github.io/json/reference/json-ld/context/) for the JSON document. Models should use `dtmi:dtdl:context;2`. |
 | `displayName` | [optional] Gives you the option to define a friendly name for the model. |
-| `contents` | All remaining interface data is placed here, as an array of attribute definitions. Each attribute must provide a `@type` (`property`, `telemetry`, `command`, `relationship`, or `component`) to identify the sort of interface information it describes, and then a set of properties that define the actual attribute (for example, `name` and `schema` to define a `property`). |
+| `contents` | All remaining interface data is placed here, as an array of attribute definitions. Each attribute must provide a `@type` (`Property`, `Telemetry`, `Command`, `Relationship`, or `Component`) to identify the sort of interface information it describes, and then a set of properties that define the actual attribute (for example, `name` and `schema` to define a `Property`). |
 
 #### Example model
 
@@ -103,7 +103,7 @@ For a comprehensive list of the fields that may appear as part of a property, se
 
 ### Difference between properties and telemetry
 
-Here's some guidance on conceptually distinguishing between DTDL property and telemetry in Azure Digital Twins.
+Here's some guidance on conceptually distinguishing between DTDL properties and telemetry in Azure Digital Twins.
 * *Properties* are expected to have backing storage, which means that you can read a property at any time and retrieve its value. If the property is writable, you can also store a value in the property.  
 * *Telemetry* is more like a stream of events; it's a set of data messages that have short lifespans. If you don't set up listening for the event and actions to take when it happens, there's no trace of the event at a later time. You can't come back to it and read it later. 
   - In C# terms, telemetry is like a C# event. 

articles/digital-twins/concepts-security.md

@@ -36,7 +36,7 @@ With Azure AD, access is a two-step process. When a security principal (a user,
 1. First, the security principal's identity is authenticated, and an OAuth 2.0 token is returned.
 2. Next, the token is passed as part of a request to the Azure Digital Twins service, to authorize access to the specified resource.
 
-The authentication step requires any application request to contain an OAuth 2.0 access token at runtime. If an application is running within an Azure entity such as an [Azure Functions](../azure-functions/functions-overview.md) app, it can use a managed identity to access the resources. Read more about managed identities in the next section.
+The authentication step requires any application request to contain an OAuth 2.0 access token at runtime. If an application is running within an Azure entity such as an [Azure Functions](../azure-functions/functions-overview.md) app, it can use a *managed identity* to access the resources. Read more about managed identities in the next section.
 
 The authorization step requires that an Azure role be assigned to the security principal. The roles that are assigned to a security principal determine the permissions that the principal will have. Azure Digital Twins provides Azure roles that encompass sets of permissions for Azure Digital Twins resources. These roles are described later in this article.
 

articles/digital-twins/concepts-twins-graph.md

@@ -54,7 +54,7 @@ You can initialize the properties of a twin when it's created, or set them later
 
 :::code language="csharp" source="~/digital-twins-docs-samples/sdks/csharp/twin_operations_other.cs" id="CreateTwin_noHelper":::
 
-You can also use a helper class called `BasicDigitalTwin` to store property fields in a "twin" object more directly, as an alternative to using a dictionary. For more information about the helper class and examples of its use, see the [Create a digital twin](how-to-manage-twin.md#create-a-digital-twin) section of *How-to: Manage digital twins*.
+You can also use a helper class called `BasicDigitalTwin` to store property fields in a "twin" object more directly, as an alternative to using a dictionary. For more information about the helper class and examples of its use, see [Create a digital twin](how-to-manage-twin.md#create-a-digital-twin).
 
 >[!NOTE]
 >While twin properties are treated as optional and thus don't have to be initialized, any [components](concepts-models.md#elements-of-a-model) on the twin need to be set when the twin is created. They can be empty objects, but the components themselves must exist.

articles/digital-twins/how-to-create-app-registration-cli.md

@@ -63,7 +63,7 @@ To upload the file, go to the Cloud Shell window in your browser. Select the "Up
 
 :::image type="content" source="media/how-to-set-up-instance/cloud-shell/cloud-shell-upload.png" alt-text="Screenshot of Azure Cloud Shell. The Upload icon is highlighted.":::
 
-Navigate to the *manifest.json* file on your machine and select "Open." Doing so will upload the file to the root of your Cloud Shell storage.
+Navigate to the *manifest.json* file on your machine and select **Open**. Doing so will upload the file to the root of your Cloud Shell storage.
 
 ## Create the registration
 

articles/digital-twins/how-to-create-app-registration-portal.md

@@ -94,7 +94,7 @@ To set up a client secret for your app registration, start on your app registrat
 
 ## Provide Azure Digital Twins permissions
 
-Next, configure the app registration you've created with permissions to access Azure Digital Twins. First, [create a role assignment](#create-role-assignment) for the app registration within the Azure Digital Twins instance. Then, [provide API permissions](#provide-api-permissions) for the app to read and write to the Azure Digital Twins APIs.
+Next, configure the app registration you've created with permissions to access Azure Digital Twins. First, you'll create a role assignment for the app registration within the Azure Digital Twins instance. Then, you'll provide API permissions for the app to read and write to the Azure Digital Twins APIs.
 
 ### Create role assignment
 
@@ -148,7 +148,7 @@ Select **Add permissions** when finished.
 
 #### Verify API permissions
 
-On the **API permissions** page, verify that there's now an entry for Azure Digital Twins reflecting Read/Write permissions:
+On the **API permissions** page, verify that there's now an entry for Azure Digital Twins reflecting **Read.Write** permissions:
 
 :::image type="content" source="media/how-to-create-app-registration/verify-api-permissions.png" alt-text="Screenshot of the API permissions for the Azure AD app registration in the Azure portal, showing 'Read/Write Access' for Azure Digital Twins.":::
 

articles/digital-twins/how-to-ingest-iot-hub-data.md

@@ -42,7 +42,7 @@ This how-to outlines how to send messages from IoT Hub to Azure Digital Twins, u
 > [!NOTE]
 > This example uses a straightforward ID match between the device ID and a corresponding digital twin's ID, but it is possible to provide more sophisticated mappings from the device to its twin (such as with a mapping table).
 
-Whenever a temperature telemetry event is sent by the thermostat device, a function processes the telemetry and the `temperature` property of the digital twin should update. This scenario is outlined in a diagram below:
+Whenever a temperature telemetry event is sent by the thermostat device, a function processes the telemetry and the `Temperature` property of the digital twin should update. This scenario is outlined in a diagram below:
 
 :::image type="content" source="media/how-to-ingest-iot-hub-data/events.png" alt-text="Diagram of IoT Hub device sending Temperature telemetry to a function in Azure, which updates a temperature property on a twin in Azure Digital Twins." border="false":::
 

articles/digital-twins/how-to-integrate-azure-signalr.md

@@ -61,8 +61,8 @@ Leave the browser window open to the Azure portal, as you'll use it again in the
 ## Publish and configure the Azure Functions app
 
 In this section, you'll set up two Azure functions:
-* "negotiate" - A HTTP trigger function. It uses the *SignalRConnectionInfo* input binding to generate and return valid connection information.
-* "broadcast" - An [Event Grid](../event-grid/overview.md) trigger function. It receives Azure Digital Twins telemetry data through the event grid, and uses the output binding of the SignalR instance you created in the previous step to broadcast the message to all connected client applications.
+* negotiate - A HTTP trigger function. It uses the *SignalRConnectionInfo* input binding to generate and return valid connection information.
+* broadcast - An [Event Grid](../event-grid/overview.md) trigger function. It receives Azure Digital Twins telemetry data through the event grid, and uses the output binding of the SignalR instance you created in the previous step to broadcast the message to all connected client applications.
 
 Start Visual Studio (or another code editor of your choice), and open the code solution in the *digital-twins-samples-master > ADTSampleApp* folder. Then do the following steps to create the functions:
 

articles/digital-twins/how-to-integrate-logic-apps.md

@@ -83,7 +83,7 @@ Navigate to the downloaded folder and unzip it.
 The custom Swagger for this tutorial is located in the *digital-twins-custom-swaggers-main\LogicApps* folder. This folder contains subfolders called *stable* and *preview*, both of which hold different versions of the Swagger organized by date. The folder with the most recent date will contain the latest copy of the Swagger definition file. Whichever version you select, the Swagger file is named *digitaltwins.json*.
 
 > [!NOTE]
-> Unless you're working with a preview feature, it's generally recommended to use the most recent "stable" version of the Swagger file. However, earlier versions and preview versions of the Swagger file are also still supported. 
+> Unless you're working with a preview feature, it's generally recommended to use the most recent stable version of the Swagger file. However, earlier versions and preview versions of the Swagger file are also still supported. 
 
 Next, go to your connector's Overview page in the [Azure portal](https://portal.azure.com) and select **Edit**.
 
@@ -100,21 +100,21 @@ In the **Edit Logic Apps Custom Connector** page that follows, configure this in
     - **Description**: Fill whatever values you want.
     - **Connect via on-premises data gateway**: **Toggled off** (leave default)
     - **Scheme**: **HTTPS** (leave default)
-    - **Host**: The *host name* of your Azure Digital Twins instance.
-    - **Base URL**: **/** (leave default)
+    - **Host**: The host name of your Azure Digital Twins instance.
+    - **Base URL**: */* (leave default)
 
 Then, select the **Security** button at the bottom of the window to continue to the next configuration step.
 
 :::image type="content" source="media/how-to-integrate-logic-apps/configure-next.png" alt-text="Screenshot of the bottom of the 'Edit Logic Apps Custom Connector' page. Highlight around button to continue to Security.":::
 
 In the Security step, select **Edit** and configure this information:
-* **Authentication type**: *OAuth 2.0*
+* **Authentication type**: **OAuth 2.0**
 * **OAuth 2.0**:
-    - **Identity provider**: *Azure Active Directory*
-    - **Client ID**: The *Application (client) ID* for the Azure AD app registration you created in [Prerequisites](#prerequisites)
+    - **Identity provider**: **Azure Active Directory**
+    - **Client ID**: The Application (client) ID for the Azure AD app registration you created in [Prerequisites](#prerequisites)
     - **Client secret**: The Client secret from the app registration 
     - **Login URL**: `https://login.windows.net` (leave default)
-    - **Tenant ID**: The *Directory (tenant) ID* for your Azure AD app registration
+    - **Tenant ID**: The Directory (tenant) ID for your Azure AD app registration
     - **Resource URL**: *0b07f429-9f4b-4714-9392-cc5e8e80c8b0*
     - **Scope**: *Directory.AccessAsUser.All*
     - **Redirect URL**: (leave default for now)
@@ -142,7 +142,7 @@ Under **Authentication** from the registration's menu, add a URI.
 
 :::image type="content" source="media/how-to-integrate-logic-apps/add-uri.png" alt-text="Screenshot of the Authentication page for the app registration in the Azure portal, highlighting the 'Add a URI' button and the 'Authentication' menu."::: 
 
-Enter the custom connector's Redirect URL into the new field, and select the **Save** icon.
+Enter the custom connector's redirect URL into the new field, and select the **Save** icon.
 
 :::image type="content" source="media/how-to-integrate-logic-apps/save-uri.png" alt-text="Screenshot of the Authentication page for the app registration in the Azure portal, highlighting the new redirect URL and the 'Save' button.":::