minor formatting fixes

Author: MScalopez

learn-pr/wwl-data-ai/configure-azure-cosmos-db-sql-api-sdk/includes/4-implement-threading-parallelism.md

@@ -261,7 +261,7 @@ Avoid blocking asynchronous execution by improperly using `.then()` or `.catch()
 
 The JavaScript SDK includes built-in iterators to retrieve query results efficiently without blocking other operations. Avoid eagerly collecting all query results, as it can consume a large amount of memory and block other operations.
 
-### Inefficient example:
+### Inefficient example
 
 ```javascript
 const results = await container.items
@@ -270,7 +270,7 @@ const results = await container.items
 console.log(results.resources);
 ```
 
-### Efficient example using an iterator:
+### Efficient example using an iterator
 
 ```javascript
 const iterator = container.items.query(

learn-pr/wwl-data-ai/configure-azure-cosmos-db-sql-api-sdk/includes/5-configure-logging.md

@@ -304,14 +304,14 @@ Logging can be enabled either through an environment variable or programmaticall
 
 Set the `AZURE_LOG_LEVEL` environment variable before starting your application.
 
-#### On macOS/Linux:
+#### On macOS/Linux
 
 ```bash
 export AZURE_LOG_LEVEL=info
 node your-app.js
 ```
 
-#### On Windows:
+#### On Windows
 
 ```cmd
 set AZURE_LOG_LEVEL=info

learn-pr/wwl-data-ai/perform-cross-document-transactional-operations-azure-cosmos-db-sql-api/includes/5-implement-optimistic-concurrency-control.md

@@ -17,7 +17,7 @@ await container.UpsertItemAsync<Product>(product, partitionKey);
 
 Since read and write in this example are distinct operations, there's a latency between these operations. This latency is represented in this diagram as *n*.
 
-![N latency between read and update](../media/5-latency.png)
+![Diagram of the N latency between read and update.](../media/5-latency.png)
 
 This latency can be as short as milliseconds or seconds in computer code but could still be catastrophic enough to lose potential updates. Some user-facing applications, where user input causes a longer latency between a read and update operation, can cause a longer *n* value and a higher potential for lost updates. This issue can be resolved by implementing **optimistic concurrency control**.
 
@@ -82,7 +82,7 @@ container.upsert_item(body=product)
 
 Since read and write in this example are distinct operations, there's a latency between these operations. This latency is represented in this diagram as *n*.
 
-![N latency between read and update](../media/5-latency.png)
+![Diagram of the N latency between read and update.](../media/5-latency.png)
 
 This latency can be as short as milliseconds or seconds in computer code but could still be catastrophic enough to lose potential updates. Some user-facing applications, where user input causes a longer latency between a read and update operation, can cause a longer *n* value and a higher potential for lost updates. This issue can be resolved by implementing **optimistic concurrency control**.
 
@@ -156,7 +156,7 @@ await container.items.upsert(product);
 
 Since read and write in this example are distinct operations, there's a latency between these operations. This latency is represented in this diagram as *n*.
 
-![N latency between read and update](../media/5-latency.png)
+![Diagram of the N latency between read and update.](../media/5-latency.png)
 
 This latency can be as short as milliseconds or seconds in computer code but could still be catastrophic enough to lose potential updates. Some user-facing applications, where user input causes a longer latency between a read and update operation, can cause a longer *n* value and a higher potential for lost updates. This issue can be resolved by implementing **optimistic concurrency control**.