chore: replace i.e. and e.g.

cds/cxl.md

@@ -234,7 +234,7 @@ This syntax diagram describes the possible expressions:
 
   ### In Queries
 
-  Expressions can be used in various parts of a query, e.g., on the select list, in the where clause, in order by clauses, and more:
+  Expressions can be used in various parts of a query, for example,, on the select list, in the where clause, in order by clauses, and more:
 
   ```cds live
   SELECT from Books {

cds/models.md

@@ -20,7 +20,7 @@ For example, a *data model describes the type structure (commonly also called *'
 
 ### Representations
 
-Models can come in different *representations*, which follow different *syntaxes*. For example, we use the *CDL* syntax for *human-readable* representations of CDS models, while CSN is an *object notation*, i.e. a special form of *syntax*, used for *machine-readable* representations of CDS models. 
+Models can come in different *representations*, which follow different *syntaxes*. For example, we use the *CDL* syntax for *human-readable* representations of CDS models, while CSN is an *object notation*, that is a special form of *syntax*, used for *machine-readable* representations of CDS models. 
 
 ::: details On CSN representations... 
 

cds/types.md

@@ -24,8 +24,8 @@ ANSI SQL types, when deployed to a relational database (concrete mappings to spe
 | `UInt8`                | Unsigned 8-bit integer, range *[ 0 ... 255 ]*                          | _TINYINT_      |
 | `Decimal`(`p`,`s`)     | Decimal with precision `p` and scale `s`                               | _DECIMAL_      |
 | `Double`               | Floating point with binary mantissa                                    | _DOUBLE_       |
-| `Date`                 | e.g. `2022-12-31`                                                      | _DATE_         |
-| `Time`                 | e.g. `23:59:59`                                                        | _TIME_         |
+| `Date`                 | for example, `2022-12-31`                                                      | _DATE_         |
+| `Time`                 | for example, `23:59:59`                                                        | _TIME_         |
 | `DateTime`             | _sec_ precision                                                        | _TIMESTAMP_    |
 | `Timestamp`            | _µs_ precision, with up to 7 fractional digits                         | _TIMESTAMP_    |
 | `String` (`length`)    | Default *length*: 255; on HANA: 5000                                   | _NVARCHAR_     |

get-started/bookshop.md

@@ -135,7 +135,7 @@ entity Genres : sap.common.CodeList {
 
 ###### Focus on Domain
 > [!tip] Primary Focus on Domain
-> Strive to keep your domain models simple, concise and comprehensible, focused on the core concepts of your domain, i.e., [_“Keep it simple, stupid!”_](https://en.wikipedia.org/wiki/kiss_principle). Factor out secondary concerns into separate sources, which _extend_ and _annotate_ the core models.\
+> Strive to keep your domain models simple, concise and comprehensible, focused on the core concepts of your domain, that is, [_“Keep it simple, stupid!”_](https://en.wikipedia.org/wiki/kiss_principle). Factor out secondary concerns into separate sources, which _extend_ and _annotate_ the core models.\
 > See also: [_Separation of Concerns_](#separation-of-concerns).
 
 [Learn more about _Domain Modeling_.](../guides/domain/index){ .learn-more}
@@ -597,7 +597,7 @@ We can also send such OData requests programmatically, for example, doing the ve
     await cds.service.bindings
     ```
     ::: details About _cds.service.bindings_ ...
-    The `cds.service.bindings` command fetches the service bindings from a running CAP server instance in another process, and makes them available in the current process, e.g., within `cds repl`.
+    The `cds.service.bindings` command fetches the service bindings from a running CAP server instance in another process, and makes them available in the current process, for example, within `cds repl`.
     ```js
     [cds] - using bindings from: { registry: '~/.cds-services.json' }
     Bindings {

get-started/concepts.md

@@ -44,7 +44,7 @@ The major building blocks are as follows:
 
 - [**Core Data Services** (CDS)](../cds/) — CAP's universal modeling language, and the very backbone of everything; used to capture domain knowledge, generating database schemas, translating to and from various API languages, and most important: fueling generic runtimes to automatically serve request out of the box.
 
-- [**Service Runtimes**](../guides/services/providing-services) for [Node.js](../node.js/) and [Java](../java/) — providing the core frameworks for services, generic providers to serve requests automatically, database support for SAP HANA, SQLite, and PostgreSQL, and protocol adaptors for REST, OData, GraphQL, ...
+- [**Service Runtimes**](../guides/services/providing-services) for [Node.js](../node.js/) and [Java](../java/) — providing the core frameworks for services, generic providers to serve requests automatically, database support for SAP HANA, SQLite, and PostgreSQL, and protocol adapters for REST, OData, GraphQL, ...
 
 - [**Platform Integrations**](../plugins/) — providing CAP-level service interfaces (*'[Calesi](#the-calesi-pattern)'*) to cloud platform services in platform-agnostic ways, as much as possible. Some of these are provided out of the box, others as plugins.
 
@@ -150,7 +150,7 @@ INNER JOIN Countries as country ON country.code = author.country_code
 -- the actual filter condition:
 WHERE country.code = 'GB';
 ```
-Path expressions in *infix filters*  become *SEMI JOINs*, e.g.using `IN`:
+Path expressions in *infix filters*  become *SEMI JOINs*, for example, using `IN`:
 ```sql
 CREATE VIEW EnglishBooks AS SELECT * FROM Books
 -- for Association Books:author:
@@ -702,12 +702,15 @@ Your application models are your services, also served automatically by generic
 
 ### Protocol Adapters
 
-Behind the scenes, i.e., in the **outer hexagon** containing stuff, you as an application developer should not see, the CAP runtime employs Protocol Adapters, which translate requests from (and to) low-level protocols like HTTP, REST, OData, GraphQL, ... to protocol-agnostic CAP requests and queries.
+Behind the scene - that is, in the **outer hexagon** containing stuff, you as an application developer should not see - the CAP runtime employs Protocol Adapters, which translate requests from (and to) low-level protocols like HTTP, REST, OData, GraphQL, ... to protocol-agnostic CAP requests and queries for inbound and outbound communication.
 
-- for ***inbound*** communication → i.e., requests your application *receives*, as well as as...
-- for ***outbound*** communication → i.e., requests your application *sends* to other services.
+--> ***Inbound*** Communication 
+: Requests your application *receives*.
 
-In effect your service implementations stay agnostic to (wire) protocols, which allows us to exchange protocols, replace targets by mocks, do fast inner loop development in airplane mode, ... even change topologies from a monolith to micro services and vice versa late in time.
+--> ***Outbound*** Communication
+: Requests your application *sends* to other services.
+
+In effect your service implementations stay agnostic to (wire) protocols, which allows you to exchange protocols, replace targets by mocks, do fast inner loop development in airplane mode, ... even change topologies from a monolith to micro services and vice versa late in time.
 
 ![protocol-adapters.drawio](./assets/concepts/protocol-adapters.drawio.svg)
 

guides/databases/cdl-to-ddl.md

@@ -735,7 +735,7 @@ CREATE VIEW Bar AS SELECT ... FROM Foo; -- skipped [!code --]
 > All parts of the view definition not relevant for the signature, such as `where`, `group by`, `having`, `order by`, or `limit`, are ignored.
 
 > [!tip] Use Case: Replica Caching Tables
-A common use case for this annotation is to create projections on entities from imported APIs, i.e., so-called _consumption views_, and at the same time use them as replica cache tables.
+A common use case for this annotation is to create projections on entities from imported APIs, so-called _consumption views_, and at the same time use them as replica cache tables.
 
 
 

guides/databases/initial-data.md

@@ -138,7 +138,7 @@ cds:
 ```
 :::
 
-Use `cds env` to check which configuration is active in your current profile, e.g.:
+Use `cds env` to check which configuration is active in your current profile, for example:
 ```shell
 cds env requires.db.data --profile development
 ```

guides/databases/schema-evolution.md

@@ -115,7 +115,7 @@ Let's simulate the workflow with the [@capire/bookshop](https://github.com/capir
 Some changes to the CDS model are considered disallowed in the context of schema evolution, as they could lead to data loss or inconsistencies. The following list shows examples of such changes:
 
 - Renaming entities or fields (instead, add new ones and migrate data)
-- Changing data types in incompatible ways (e.g., from String to Integer)
+- Changing data types in incompatible ways (for example, from String to Integer)
 - Removing entities or fields (instead, consider deprecating them first)
 - Reducing the length of strings or binary fields
 - Reducing the precision of numeric fields

guides/deploy/cicd.md

@@ -103,13 +103,13 @@ For the actual release we want to override org-wide sandbox variables to deploy
 
 Go to **Settings** → **Environments** → **New environment** → enter "Production".
 
-Now override org-wide variables (e.g. `CF_ORG` and `CF_SPACE` in Cloud Foundry) to use a dedicated subaccount you created for the release deployment.
+Now override org-wide variables (for example `CF_ORG` and `CF_SPACE` in Cloud Foundry) to use a dedicated subaccount you created for the release deployment.
 
 #### Publish the release
 
 On your repository front page go to `Releases` → `Draft a new release` → `Select tag`.
 
-Now enter a tag name, e.g. `v1.0.0` and select `Create new tag: v1.0.0 on publish`.
+Now enter a tag name, for example, `v1.0.0` and select `Create new tag: v1.0.0 on publish`.
 
 You can optionally add a release title and release notes. Hit **Publish release** once you're ready.
 

guides/integration/calesi.md

@@ -55,7 +55,7 @@ The graphic below illustrates what happened here:
 ![Diagram illustrating CAP-level service integration showing two scenarios: Local services where Consumer connects to Service via CQL, and Remote services where Consumer connects to Proxy via CQL, Proxy connects to Protocol Adapter via OData, and Protocol Adapter connects to Service via CQL.
 ](assets/remoting.drawio.svg)
 
-Remote CAP services can be consumed using the same high-level, uniform APIs as for local services – i.e., **_as if they were local_**. `cds.connect` automatically constructs remote proxies, which translate all local requests into protocol-specific ones, sent to remote services. Thereby also taking care of all connectivity, remote communication, principal propagation, as well as generic resilience.
+Remote CAP services can be consumed using the same high-level, uniform APIs as for local services – that is, **_as if they were local_**. `cds.connect` automatically constructs remote proxies, which translate all local requests into protocol-specific ones, sent to remote services. Thereby also taking care of all connectivity, remote communication, principal propagation, as well as generic resilience.
 
 > [!note] Model Free
 >
@@ -459,7 +459,7 @@ This allows us to update imported APIs later on using standard commands like `np
 
 You can also `cds import` APIs from other sources, such as OData APIs for customer data from SAP S/4 HANA systems:
 
-1. Get an [_OData EDMX_](https://api.sap.com/api/API_BUSINESS_PARTNER/overview) source, e.g., from [*SAP Business Accelerator Hub*](https://api.sap.com):
+1. Get an [_OData EDMX_](https://api.sap.com/api/API_BUSINESS_PARTNER/overview) source, for example, from [*SAP Business Accelerator Hub*](https://api.sap.com):
 
    ::: details Detailed steps through SAP Business Accelerator Hub ...
       - Open https://api.sap.com in your browser
@@ -630,7 +630,7 @@ namespace sap.capire.s4;
 
 The noteworthy aspects here are:
 
-- We map names to match our domain, e.g., `A_Business_Partner` -> `Customers`, and choose simpler names for the elements we want to use.
+- We map names to match our domain, for example, `A_Business_Partner` -> `Customers`, and choose simpler names for the elements we want to use.
 
 - For entity `Flights` we flatten data from associations directly into the consumption view. This is another [denormalization](#using-denormalized-views) to make life easier for us in the xtravels app.
 
@@ -860,9 +860,9 @@ const xflights = await cds.connect.to ('sap.capire.flights.data')
 
 The `cds.connect.to(<service>)` function used here is the single common way to address service instances. It's used for and works the same way for both, local as well as remote services:
 
-- for **local** services, it returns the local service providers – i.e., instances of [`cds.ApplicationService`](../../node.js/app-services), or your application-specific subclases thereof.
+- for **local** services, it returns the local service providers – that is, instances of [`cds.ApplicationService`](../../node.js/app-services), or your application-specific subclasses thereof.
 
-- for **remote** services, it returns a remote service proxy – i.e., instances of [`cds.RemoteService`](../../node.js/remote-services), generically constructed by the client libs.
+- for **remote** services, it returns a remote service proxy – that is, instances of [`cds.RemoteService`](../../node.js/remote-services), generically constructed by the client libs.
 
 ![Diagram illustrating CAP-level service integration showing two scenarios: Local services where Consumer connects to Service via CQL, and Remote services where Consumer connects to Proxy via CQL, Proxy connects to Protocol Adapter via OData, and Protocol Adapter connects to Service via CQL.
 ](assets/remoting.drawio.svg)
@@ -1080,7 +1080,7 @@ await s4.run (q2)
 > Modifying queries prior to forwarding them to remote services is a powerful technique to implement advanced integration scenarios. For example, you can adapt queries to the capabilities of target services, implement custom filtering, paging, or sorting logic, or even split and merge queries across multiple services.
 
 ::: details First-Class Query Objects
-On a side note: We leverage key principles of [_first-class objects_](https://google.com/search?q=first+class+objects+programming) here, as known from functional programming and dynamic languages: As queries are represented as first-class CQN objects, we can construct and manipulate them programmatically at runtime, pass them as arguments, and return them from functions. And, not the least, this opens the doors for things like higher-order queries, query delegation – e.g. push down to databases –, and late materialization.
+On a side note: We leverage key principles of [_first-class objects_](https://google.com/search?q=first+class+objects+programming) here, as known from functional programming and dynamic languages: As queries are represented as first-class CQN objects, we can construct and manipulate them programmatically at runtime, pass them as arguments, and return them from functions. And, not the least, this opens the doors for things like higher-order queries, query delegation – for example push down to databases –, and late materialization.
 :::
 
 > [!warning] Always Clone Before Modifying
@@ -1200,7 +1200,7 @@ Note that for the handler above, incoming requests always refer to:
 
 In effect, we are delegating a query to the S/4 service, which refers to an entity actually not known to that remote service. How could that work at all?
 
-It works because we fuelled the CAP runtime with CDS models, so the generic handlers detect such situations, and automatically translate delegated queries into valid queries targeted to underlying remote entities – i.e. `A_BusinessPartner` in our example. When doing so, all column references in select clauses, where clauses, etc., are translated and delegated as well, and the results' structure transformed back to that of the original target – i.e., `TravelService.Customers` above.
+It works because we fuelled the CAP runtime with CDS models, so the generic handlers detect such situations, and automatically translate delegated queries into valid queries targeted to underlying remote entities – that is, `A_BusinessPartner` in our example. When doing so, all column references in select clauses, where clauses, etc., are translated and delegated as well, and the results' structure transformed back to that of the original target – that is, `TravelService.Customers` above.
 
 
 
@@ -1238,7 +1238,7 @@ await SELECT.from (Bookings) .where`Flight.ID in ${flightIDs}`
 :::
 
 > [!tip] What is 'Navigation'?
-> The term 'navigation' commonly refers to traversing associations between entities in queries. In CAP, this is typically expressed using [path expressions](../../cds/cql#path-expressions) along (chains of) associations – e.g., `flight.origin.name` –, which can show up in all query clauses (_select_, _from_, _where_, _order by_, and _group by_).
+> The term 'navigation' commonly refers to traversing associations between entities in queries. In CAP, this is typically expressed using [path expressions](../../cds/cql#path-expressions) along (chains of) associations – for example, `flight.origin.name` –, which can show up in all query clauses (_select_, _from_, _where_, _order by_, and _group by_).
 
 
 ### Expands

guides/integration/data-federation.md

@@ -102,7 +102,7 @@ npm install
 
 ## Federated Consumption Views
 
-Tag [consumption views](calesi#consumption-views) with the `@federated` annotation, to express your intent to have that data federated, i.e. in close access locally. For example, we did so in our consumption view for entities imported from XFlights as well as for the S/4 Business Partners entity:
+Tag [consumption views](calesi#consumption-views) with the `@federated` annotation, to express your intent to have that data federated, that is, in close access locally. For example, we did so in our consumption view for entities imported from XFlights as well as for the S/4 Business Partners entity:
 
 ::: code-group
 
@@ -183,7 +183,7 @@ Let's have a closer look at this code, which handles these main tasks:
 3. **Replicate Data** – Finally, the `replicate` handler implements a simple polling-based data federation strategy, based on `modifiedAt` timestamps (lines 28-32), with the actual call to remote happening on line 29. 
 
 > [!tip] CAP-level Querying -> agnostic to databases & protocols
-> We work with **database-agnostic** and **protocol-agnostic** [CQL queries](../../cds/cql) both for interacting with the local database as well as for querying remote services. In effect, we got a fully generic solution for replication, i.e., it works for **_any_** remote service that supports OData, or HCQL.
+> We work with **database-agnostic** and **protocol-agnostic** [CQL queries](../../cds/cql) both for interacting with the local database as well as for querying remote services. In effect, we got a fully generic solution for replication, that is, it works for **_any_** remote service that supports OData, or HCQL.
 
 
 ## Test Drive Locally

guides/integration/platform/attachments.md

@@ -41,7 +41,7 @@
     }
     ```
 
- 5. **Implement Attachment Logic**: In your service implementation file (e.g., `srv/your-service.js`), implement the logic to handle attachment operations such as upload, download, and delete.
+ 5. **Implement Attachment Logic**: In your service implementation file (for example, `srv/your-service.js`), implement the logic to handle attachment operations such as upload, download, and delete.
 
  6. **Test Your Application**: Run your CAP application and test the attachment functionality to ensure everything is working as expected.