Update over_the_wire.md

Author: oblomov-dev

docs/advanced/technical/over_the_wire.md

@@ -1,26 +1,26 @@
 # Key Idea: Over-the-Wire in abap2UI5
 
-The key idea of **abap2UI5** is to apply the principles of **Over-the-Wire (OtW)** web development to the SAP ecosystem.
+The key idea of **abap2UI5** is to apply the principles of **Over-the-Wire** web development to the SAP ecosystem.
 
-Over-the-Wire refers to a pattern where the **server is responsible for rendering the user interface (UI)** and sends **ready-to-render HTML fragments** to the browser. This avoids complex client-side frameworks and keeps the frontend lean and maintainable.
+Over-the-Wire refers to a pattern where the server is responsible for rendering the user interface and sends ready-to-render HTML fragments to the browser. This avoids complex client-side frameworks and keeps the frontend lean and maintainable.
 
-While this approach is widely used in frameworks like Hotwire, Livewire, or Phoenix LiveView, **abap2UI5 adapts this idea for SAP**, using the SAPUI5 runtime to render the UI based on server-provided definitions.
+While this approach is widely used in frameworks like Hotwire, Livewire, or Phoenix LiveView, **abap2UI5 adapts this idea for the SAP technoligal environment**, using the SAP UI5 framework to render the UI based on server-provided definitions created in ABAP.
 
 ### History: From SSR to Over-the-Wire
 
-In the early days of web development, **Server-Side Rendering (SSR)** was the standard approach. Every user interaction triggered a request to the server, which returned a fully rendered HTML page.
+In the early days of web development, Server-Side Rendering (SSR) was the standard approach. Every user interaction triggered a request to the server, which returned a fully rendered HTML page.
 
-With the rise of **Single Page Applications (SPAs)**, UI rendering shifted to the browser. SPAs request **raw data (e.g., JSON)** from the server and build the UI dynamically using JavaScript frameworks like React, Angular, or Vue.
+With the rise of Single Page Applications (SPAs), UI rendering shifted to the browser. SPAs request raw data (e.g., JSON) from the server typically send via OData and build the UI dynamically using JavaScript frameworks like React, Angular, or Vue at the frontend.
 
 While SPAs enable rich client-side experiences, they also introduce significant complexity:
 - API layers and data contracts
 - Separate frontend-backend development
 - Complex build & deployment pipelines
 
-As a response to this complexity, the **Over-the-Wire approach re-emerged**:
-- The **server renders UI fragments**, not full pages.
-- The **browser simply inserts those fragments** into the page.
-- The frontend remains simple and declarative.
+As a response to this complexity, the Over-the-Wire approach re-emerged:
+- The server renders UI fragments, not full pages
+- The browser simply inserts those fragments into the page
+- The frontend remains simple and declarative
 
 ##### Architectural Comparison
 
@@ -32,7 +32,7 @@ As a response to this complexity, the **Over-the-Wire approach re-emerged**:
 
 ##### Over-the-Wire Frameworks
 
-The followring frameworks are modern implementations of this concept.
+The followring frameworks are implementations of this concept.
 
 | Framework | Key Use Case | Technology |
 |-----------|--------------|------------|
@@ -48,25 +48,25 @@ The followring frameworks are modern implementations of this concept.
 
 **abap2UI5** adopts the Over-the-Wire principle but tailors it to SAP's technical environment:
 
-- The **ABAP backend defines the UI** via a **view and a view model**.
-- This structured data is sent to the browser.
-- The **SAPUI5 runtime (static frontend code)** renders the UI dynamically based on this data.
-- The frontend code itself is **never generated dynamically**. It remains stable and generic.
-- All business logic, UI definitions, and dynamic behavior are maintained on the backend.
+- The ABAP backend defines the UI via a UI5 XML View and UI5 JSON View-Model
+- This data is sent to the browser
+- A static UI5 frontend app renders the UI dynamically based on this responses
+- The frontend code itself is never generated dynamically. It remains stable and generic.
+- All business logic, UI definitions, and dynamic behavior are maintained on the backend in an ABAP Class
 
 ##### Key Characteristics:
-- Frontend code is astatic UI5 app and send with the first request
+- Frontend code is a static UI5 app and send with the first request
 - Backend fully controls UI definitions and logic
 - No separate frontend development needed, all apps are pure backend abap artifacts
 - Aligns with SAP's technology stack (ABAP & UI5) while following Over-the-Wire principles
 
 ##### Benefits for SAP Applications
 
-- **Reduced Frontend Complexity**: No need for custom JavaScript development per app.
+- **Reduced Frontend Complexity**: No need for custom JavaScript development
 - **Faster Development Cycles**: UI and logic are controlled via ABAP in the backend
-- **Maintainable Architecture**: Reuse of SAPUI5 runtime, minimal frontend code.
-- **Seamless SAP Integration**: abap2UI5 app fits into existing ABAP Stacks on any release
-- **Ideal for Business Applications**: CRUD-heavy apps, forms, dashboards, transactions.
+- **Maintainable Architecture**: No frontend code, all apps are ABAP Classes
+- **Seamless SAP Integration**: abap2UI5 app run on any ERP and S/4 release
+- **Ideal for Business Applications**: CRUD-heavy apps, forms, dashboards, transactions etc.
 
 ##### Limitations to Consider
 
@@ -77,8 +77,7 @@ While Over-the-Wire (and abap2UI5) offers many advantages, it may not be suitabl
 
 ### Conclusion
 
-The **key idea of abap2UI5** is to apply the simplicity of the Over-the-Wire approach to the SAP world.  
-It enables building efficient, maintainable business applications by shifting UI control back to the backend, while using SAPUI5 as a stable frontend runtime.
+The **key idea of abap2UI5** is to apply the simplicity of the Over-the-Wire approach to the SAP world. It enables building efficient, maintainable business applications by shifting UI control back to the backend, while using SAP UI5 as a frontend framework.
 
 This reduces development complexity, shortens time-to-market, and ensures a clean architecture — without giving up the flexibility of SAPUI5.