More edits to this page

graph/patterns/subsets.md

@@ -2,27 +2,23 @@
 
 Microsoft Graph API Design Pattern
 
-The modeling collection subsets pattern is the modeling state associated to a collection that may include all instances, an included subset, an excluded subset, no instances, or any combinations of the preceding items.
+*The modeling collection subsets pattern is the modeling state associated to a collection that may include all instances, an included subset, an excluded subset, no instances, or any combinations of the preceding items.*
+
+## Problem
 
 A common pattern is to apply a policy or state to a collection of objects. 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.
 
-## Problem
-
---------
-
 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).
 
 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
+**Base type**
 
 ```xml
     <ComplexType Name="membership" IsAbstract="true">
@@ -37,7 +33,7 @@ Base type
     </Enum>
 ```
 
-Derived types
+**Derived types**
 
 ```xml
     <ComplexType Name="noMembership" BaseType="graph.membership"/>
@@ -75,8 +71,6 @@ Be aware that the name values and types in the preceding examples are just examp
 
 ## When to use this pattern
 
---------
-
 Use this pattern when supporting two or more collection states of the following, where at least one of the states is a subset variant:
 
 - All targets
@@ -88,17 +82,15 @@ 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).
 
 ## Example
 
---------
-
+```http
 GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/
+```
 
-_Note: unrelated properties on entities are omitted for easier readability_
+_Note: Unrelated properties on entities are omitted for easier readability._
 
 ```json
 {
@@ -135,9 +127,11 @@ _Note: unrelated properties on entities are omitted for easier readability_
 }
 ```
 
+```http
 POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/
+```
 
-_Note: unrelated properties on entities are omitted for easier readability_
+_Note: Unrelated properties on entities are omitted for easier readability._
 
 ```json
 {
@@ -156,9 +150,11 @@ _Note: unrelated properties on entities are omitted for easier readability_
 
 or
 
+```http
 POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/
+```
 
-_Note: unrelated properties on entities are omitted for easier readability_
+_Note: Unrelated properties on entities are omitted for easier readability._
 
 ```json
 {