Updates use of element.xml notation

Author: nicodecleyre

docs/sp-add-ins/add-a-custom-content-type-to-a-sharepoint-hosted-sharepoint-add-in.md

@@ -69,12 +69,12 @@ In this article, you add a custom content type to the Employee Orientation Share
 
 1. Select **OK** to close the dialog box, and then save and close the file.
 
-### Modify the schema.xml file and element.xml file
+### Modify the schema.xml file and elements.xml file
 
 1. Open the schema.xml file.
 1. Find the **Fields** element. It should have three **Field** elements: **Title**, **Division**, and **OrientationStage**. (These elements may be on a single line in this generated file. If so, separate them with line breaks.)
-1. Leave the file open, and in **Solution Explorer**, expand the **Site Columns** folder and the **Division** node, and then open the elements.xml file for **Division**. The **Field** element for **Division** in schema.xml should exactly duplicate the **Field** element in the **Division** elements.xml. If there is not an exact match, copy the **Field** element from the site column elements.xml file and paste it in place of the mismatched **Field** element in the schema.xml file. Close the element.xml file.
-1. Open the elements.xml file for **OrientationStage**. Here, too, there must be an exact match of the  **Field** elements in the two files for **OrientationStage**, including all child elements, such as the **CHOICES** and **MAPPINGS** elements. If there isn't, copy the **Field** in the elements.xml file and paste it in place of the mismatched **Field** element in the schema.xml file. Close the element.xml file.
+1. Leave the file open, and in **Solution Explorer**, expand the **Site Columns** folder and the **Division** node, and then open the elements.xml file for **Division**. The **Field** element for **Division** in schema.xml should exactly duplicate the **Field** element in the **Division** elements.xml. If there is not an exact match, copy the **Field** element from the site column elements.xml file and paste it in place of the mismatched **Field** element in the schema.xml file. Close the elements.xml file.
+1. Open the elements.xml file for **OrientationStage**. Here, too, there must be an exact match of the  **Field** elements in the two files for **OrientationStage**, including all child elements, such as the **CHOICES** and **MAPPINGS** elements. If there isn't, copy the **Field** in the elements.xml file and paste it in place of the mismatched **Field** element in the schema.xml file. Close the elements.xml file.
 1. Still in the schema.xml file, in the **View** element whose **BaseViewID** value is "1", find the child **ViewFields** element, and then add the following two **FieldRef** elements as children of it. They may already be there but missing an **ID** attribute. If so, add the ID attribute.
 
     ```xml

docs/sp-add-ins/programmatically-deploy-a-custom-button-in-the-provider-hosted-add-in.md

@@ -105,7 +105,7 @@ The following procedure shows how to implement this strategy.
 
    - Because the custom action, that is, the custom button, was registered with the ribbon of a list *type*, it is scoped to the entire website and is in the website's collection of custom actions. So the code retrieves it from that collection.
 
-   - The value of the `action.Name` comes from the **ID** attribute of the **CustomAction** element in the element.xml file in **AddEmployeeToCorpDB**.
+   - The value of the `action.Name` comes from the **ID** attribute of the **CustomAction** element in the elements.xml file in **AddEmployeeToCorpDB**.
 
    > [!IMPORTANT]
    > **You must change the `action.Name` value in the code to match the value in your elements.xml file.** The GUID part of the name will be different. Note that there is a `"."` character between the GUID and the rest of the name. The following is an example of the line: 

docs/spfx/extensions/get-started/building-simple-cmdset-with-dialog-api.md

@@ -318,7 +318,7 @@ Possible ___location values that can be used with a ListView Command Set:
 
 Open the file **./config/package-solution.json**.
 
-The **package-solution.json** file defines the package metadata as shown in the following code. To ensure that the **element.xml** file is taken into account while the solution package is created, the default scaffolding of this file is updated to include additional details for a feature definition. This feature definition is used to provision and execute the **elements.xml** file.
+The **package-solution.json** file defines the package metadata as shown in the following code. To ensure that the **elements.xml** file is taken into account while the solution package is created, the default scaffolding of this file is updated to include additional details for a feature definition. This feature definition is used to provision and execute the **elements.xml** file.
 
 > [!NOTE]
 > You can use **ClientSideInstance.xml** to automatically deploy your extensions cross all sites in your tenant. More details around this option from [Tenant Wide Deployment of SharePoint Framework Extensions](../basics/tenant-wide-deployment-extensions.md) article. As this solution is intended configured not to use tenant-scope option, this xml file is ignored when solution is activated in the app catalog.

docs/spfx/extensions/get-started/building-simple-field-customizer.md

@@ -279,7 +279,7 @@ Look at the XML in this file. The `ClientSideComponentId` property has been auto
 
 Open the **./config/package-solution.json** file.
 
-The **package-solution.json** file defines the package metadata as shown in the following code. To ensure that the **element.xml** file is taken into account while the solution package is created, the default scaffolding of this file is updated to include additional details for a feature definition. This feature definition is used to provision and execute the **elements.xml** file.
+The **package-solution.json** file defines the package metadata as shown in the following code. To ensure that the **elements.xml** file is taken into account while the solution package is created, the default scaffolding of this file is updated to include additional details for a feature definition. This feature definition is used to provision and execute the **elements.xml** file.
 
 Also notice that the `includeClientSideAssets` attribute is set to `true`. This means the JavaScript assets will be included in the **\*.sppkg** file:
 

docs/spfx/extensions/get-started/serving-your-extension-from-sharepoint.md

@@ -83,7 +83,7 @@ For this tutorial, we don't need this file as we'll be activating solution in a
 
 ### Ensure that definitions are taken into account within the build pipeline
 
-The **./config/package-solution.json** file defines the package metadata. To ensure that the **element.xml** file is taken into account while the solution is being packaged, the default scaffolding includes the required configuration to define a Feature Framework feature definition in the solution package.
+The **./config/package-solution.json** file defines the package metadata. To ensure that the **elements.xml** file is taken into account while the solution is being packaged, the default scaffolding includes the required configuration to define a Feature Framework feature definition in the solution package.
 
 The original `elementManifests` property in the **./config/package-solution.json** file looks like this:
 

docs/spfx/web-parts/get-started/provision-sp-assets-from-package.md

@@ -74,7 +74,7 @@ To provision SharePoint assets to sites with feature framework elements, we need
 - List instances
 - List instances with custom schema
 
-### Add an element.xml file for SharePoint definitions
+### Add an elements.xml file for SharePoint definitions
 
 In the following steps, we define the needed structure to be provisioned.
 
@@ -239,7 +239,7 @@ There are a few things to take note of from this XML:
 - Make sure you define a **unique GUID** for the `id` property in the `feature` property.
 - You can technically have multiple features in the package because the `features` property is an array. However, this isn't recommended.
 - **elements.xml** is referenced under `elementManifests` so that it's properly packaged for the feature definition as an element manifest file.
-- You can have multiple **element.xml** files in the definition, and they would be executed in the order they're mentioned in the JSON definition. Typically, you should avoid using multiple **element.xml** files because this adds unnecessary complexity. You can define all needed assets in a single **element.xml** file.
+- You can have multiple **elements.xml** files in the definition, and they would be executed in the order they're mentioned in the JSON definition. Typically, you should avoid using multiple **elements.xml** files because this adds unnecessary complexity. You can define all needed assets in a single **elements.xml** file.
 
 ## Deploy and test asset provisioning