Final edit pass

Author: Linda-Editor

graph/patterns/subsets.md

@@ -6,17 +6,17 @@ Microsoft Graph API Design Pattern
 
 ## Problem
 
-A common pattern is to apply a policy or state to a collection of resources. With this, there also comes the question of how to model cases where we want to apply to 'all' or 'none' without having to special case these values within the collection set or introduce cross-property dependencies. Likewise, we'd like to model it in a way where it is easy to understand and interpret usage from just looking at the schema.
+A common pattern is to apply a policy or state to a collection of resources. With this, there also comes the question of how to model cases where we want to apply to `all` or `none` without having to special case these values within the collection set or introduce cross-property dependencies. Likewise, we'd like to model it in a way where it is easy to understand and interpret usage from just looking at the schema.
 
 An example is where you have a policy that you need to be able to apply to users in an organization. You might want to support the default **None**, enablement for **All**, or enablement for **Select** users where you only grant it to a few users.
 
-Existing patterns for this either have special-cased 'strings' or have tightly coupled dependencies between two independent properties. Neither is intuitive, both require reading documentation, and neither can be inferred from the schema or within client libraries.
+Existing patterns for this either have special-cased `strings` or have tightly coupled dependencies between two independent properties. Neither is intuitive, both require reading documentation, and neither can be inferred from the schema or within client libraries.
 
 ## Solution
 
-Have an abstract base class where all 'variants' of the subset are derived types from the base subset. For more information, see the [general subtyping guidance](https://github.com/microsoft/api-guidelines/blob/graph/graph/patterns/subtypes.md).
+Have an abstract base class where all `variants` of the subset are derived types from the base subset. For more information, see the [general subtyping guidance](./subtypes.md).
 
-The abstract base class should also hold an enum for all possible variants. The purpose of including this is to allow for easier ways to do query and filter operations on variants like 'all' and 'none' without relying on `isof` functions.
+The abstract base class should also hold an enum for all possible variants. The purpose of including this is to allow for easier ways to do query and filter operations on variants like `all` and `none` without relying on `isof` functions.
 
 **Base type**
 
@@ -49,13 +49,12 @@ The abstract base class should also hold an enum for all possible variants. The
     </ComplexType>
 ```
 
-Be aware that the name values and types in the preceding examples are just examples and can be replaced with your scenario equivalent values. For example, type names don't really need to be `memberships`.The collection doesn't have to be a collection at all; it can be singular and doesn't have to be a string.
+Be aware that the name values and types in the preceding examples are just examples and can be replaced with your scenario equivalent values. For example, type names don't really need to be `memberships`. The collection doesn't have to be a collection at all; it can be singular and doesn't have to be a string.
 
-These pattern type names should satisfy the following naming conventions: 
-
-- The base type name should have the suffix "Base" and the enumeration type name should have the suffix "Kind". 
-- Derived child types should have names with enumeration values as the prefixes; for example, if the enumeration member value is `value1`, then the derived type name is `value1<type>`. 
+These pattern type names should satisfy the following naming conventions:
 
+- The base type name should have the suffix `Base`, and the enumeration type name should have the suffix `Kind`.
+- Derived child types should have names with enumeration values as the prefixes; for example, if the enumeration member value is `value1`, then the derived type name is `value1<type>`.
 
 ```xml
     <ComplexType Name="<type>Base" IsAbstract="true">
@@ -88,7 +87,7 @@ If you only ever need to support two states&mdash;All or None&mdash;without usin
 
 ## Issues and considerations
 
-Given that we are using an overarching subtype model, subtyping model limitations apply here as well; for more details, see the [subtyping documentation](https://github.com/microsoft/api-guidelines/blob/graph/graph/Modelling%20with%20Subtypes%20Pattern.md).
+Given that we are using an overarching subtype model, subtyping model limitations apply here as well; for more details, see the [subtyping documentation](./subtypes.md).
 
 ## Example