Apply suggestions from review

Co-authored-by: Sean Wheeler <[email protected]>

Author: michaeltlombardi

dsc/docs-conceptual/dsc-3.0/concepts/configurations.md

@@ -16,7 +16,7 @@ desired state of a system as data files. Configuration documents define a collec
 [DSC resource][01] instances to describe what the desired state should be, not how to put the
 system into that state. The DSC resources handle the _how_ for each instance.
 
-DSC can process configuration documents to:
+DSC processes configuration documents to:
 
 - Retrieve the current state of the defined resource instances with the `dsc config get` command.
 - Validate whether the instances are in the desired state with the `dsc config test` command.
@@ -30,11 +30,10 @@ properties define how DSC processes the document. The top-level properties for a
 - `$schema` (required) - Defines the URI for the JSON Schema the document adheres to. DSC
   uses this to know how to validate and interpret the document.
 - `resources` (required) - Defines the collection of resource instances the document manages.
-- `metadata` (optional) - Defines an arbitrary set of annotations for the document. Except for
-  metadata within the `Microsoft.DSC` property, DSC doesn't validate this data or use it directly.
-  The annotations can include notes like who authored the document, the last time someone updated
-  it, or any other information. DSC doesn't use the annotations. The metadata is for documentation
-  or other tools to use.
+- `metadata` (optional) - Defines an arbitrary set of annotations for the document. The annotations
+  can include notes like who authored the document, the last time someone updated it, or any other
+  information. With one exception, DSC doesn't use the annotations. The metadata is for
+  documentation or other tools to use.
 
   DSC applies validation to the `Microsoft.DSC` property. For more information, see the
   [DSC Configuration document metadata schema][02] reference.

dsc/docs-conceptual/dsc-3.0/concepts/enhanced-authoring.md

@@ -162,7 +162,7 @@ specific workspace.
 ```json
 "json.schemas": [
     {
-        "fileMatch": ["**/*.dsc.resource.json", ],
+        "fileMatch": ["**/*.dsc.resource.json"],
         "url": "https://aka.ms/dsc/schemas/v3/bundled/resource/manifest.vscode.json"
     }
 ]

dsc/docs-conceptual/dsc-3.0/concepts/resources.md

@@ -75,22 +75,22 @@ Most properties are one of the basic types:
 Complex properties require the property value to be an object with defined subproperties. The
 subproperties can be basic or complex, but they're usually a basic type.
 
-Resources may define their properties as read-only or write-only:
+Resources can define their properties as read-only or write-only:
 
 - A _read-only resource property_ defines metadata about an instance that the resource can retrieve
   but that a user can't directly set. You can't specify read-only properties in the desired state
   for an instance. Examples of read-only properties include the last time a file was modified or
   the author of an installed software package.
 - A _write-only resource property_ defines a value that the resource uses during a resource
-  operation but which can't be returned for the current state of an instance. Examples of
+  operation that can't be returned for the current state of an instance. Examples of
   write-only properties include credentials used to authenticate during a resource operation and
   the temporary directory to use when retrieving and unpacking a remote archive.
 
-DSC defines a set of _canonical resource properties_ which indicate that a resource participates in
+DSC defines a set of _canonical resource properties_, which indicate that a resource participates in
 shared semantics the DSC engine provides. For example, any resource that includes the `_exist`
 canonical property in its instance schema indicates that the resource manages instances that can be
 created and deleted. If a resource has the `_exist` canonical property and the `delete` capability,
-DSC can handle invoking the **Delete** operation instead of **Set** when the desired state
+DSC can invoke the **Delete** operation instead of **Set** when the desired state
 indicates the instance shouldn't exist. For more information about the available canonical
 properties, see [DSC canonical properties](../reference/schemas/resource/properties/overview.md).
 

dsc/docs-conceptual/dsc-3.0/resources/concepts/anatomy.md

@@ -44,7 +44,7 @@ At a minimum, the manifest must define:
   - A command to validate nested DSC Resources. This last option only applies to DSC group
     resources and DSC adapter resources.
 
-The manifest may define:
+The manifest can define:
 
 - The kind of resource the manifest describes: `adapter`, `group`, `importer`, or `resource`.