Merge pull request MicrosoftDocs#1524 from MicrosoftDocs/sushant-typofix

Removing "[" from webapi/web-api-types-operations.md file

Author: KumarVivek

powerapps-docs/developer/common-data-service/webapi/web-api-types-operations.md

@@ -2,7 +2,7 @@
 title: "Web API types and operations (Common Data Service)| Microsoft Docs"
 description: "This topic describes what is available for you to use vis-a-vis the Web API and will introduce important topics and how you can find information you need from the documentation generated from the service and metadata documents as well as the documentation of the system entity types, functions, and actions"
 ms.custom: ""
-ms.date: 04/22/2019
+ms.date: 04/30/2019
 ms.service: powerapps
 ms.suite: ""
 ms.tgt_pltfrm: ""
@@ -267,7 +267,7 @@ OData supports a wide range of data types but Common Data Service doesn’t use
 
 ### Lookup properties
 
-For most single-valued navigation properties you will find a computed, read-only property that uses the following naming convention: `_<name>_value` where the `<name>` matches the name of the single-valued navigation property. The exception to this pattern is when a lookup attribute of the entity can accept multiple types of entity references. A common example is how the `incident` entity `customerid` attribute may be set to a reference that is either a `contact` or `account` entity. In the <xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Single-valued navigation properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#Single-valued_navigation_properties) you will find `customerid_account` and `customerid_contact` as separate single-valued navigation properties to reflect the customer associated with an opportunity. If you set one of these single-valued navigation properties, the other will be set to null because they are both bound to the `customerid` attribute. In the [<xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#Properties) you’ll find a `_customerid_value` lookup property that contains the same value that is set for whichever of the single-valued navigation properties contain a value.  
+For most single-valued navigation properties you will find a computed, read-only property that uses the following naming convention: `_<name>_value` where the `<name>` matches the name of the single-valued navigation property. The exception to this pattern is when a lookup attribute of the entity can accept multiple types of entity references. A common example is how the `incident` entity `customerid` attribute may be set to a reference that is either a `contact` or `account` entity. In the <xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Single-valued navigation properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#Single-valued_navigation_properties) you will find `customerid_account` and `customerid_contact` as separate single-valued navigation properties to reflect the customer associated with an opportunity. If you set one of these single-valued navigation properties, the other will be set to null because they are both bound to the `customerid` attribute. In the <xref href="Microsoft.Dynamics.CRM.incident?text=incident EntityType" /> [Properties](/dynamics365/customer-engagement/web-api/incident?view=dynamics-ce-odata-9#Properties) you’ll find a `_customerid_value` lookup property that contains the same value that is set for whichever of the single-valued navigation properties contain a value.  
 
 Generally, you should avoid using lookup properties and use the corresponding single-valued navigation properties instead. These properties have been included because they may be useful for certain integration scenarios. These properties are read-only and computed because they will simply reflect the changes applied using the corresponding single-valued navigation property.