docs: misc updates on agama docs

docs/admin/developer/agama/advanced-usages.md

@@ -139,7 +139,7 @@ One way to structure the solution is the following:
 
 - Template `commons.ftlh` is imported and its macro `main` called passing `true` for `useSidebar`
 
-- The markup between `<@com.main...` and `</@com.main>` is the content of the homepage, which is "inserted" by the `main` macro when the `<#nested>` directive is reached  
+- The markup inside `<@com.main...` tag is the content to be "inserted" when the `<#nested>` directive is reached  
 
 ```
 <#-- about.ftlh -->
@@ -229,7 +229,7 @@ Note however URLs are not manipulable: an attempt to set the browser location to
 
 Additionally, the engine by default sends responses with proper HTTP headers so page contents are not cached. This is key to prevent manipulation and allows a safe usage of the browser's back button, where it will not be possible to visit past stages. 
 
-## Code transpilation
+### Code transpilation
 
 The engine has some timers running in the background. One of them [transpiles code](https://github.com/JanssenProject/jans/blob/main/jans-auth-server/agama/engine/src/main/java/io/jans/agama/timer/Transpilation.java) when a change is detected in a given flow's source (written in Agama language). The transpilation process generates vanilla Javascript code runnable through [Mozilla Rhino](https://github.com/mozilla/rhino) by using a transformation chain like  (DSL) flow code -> (ANTLR4) parse tree -> (XML) abstract syntax tree -> JS. 
 
@@ -244,7 +244,7 @@ The transformation chain guarantees that a flow written in Agama DSL cannot:
 - You can find the (ANTLR4) DSL grammar [here](https://github.com/JanssenProject/jans/blob/main/agama/transpiler/src/main/antlr4/io/jans/agama/antlr/AuthnFlow.g4).
 - The last step of the transformation chain is carried out by means of [this](https://github.com/JanssenProject/jans/blob/main/agama/transpiler/src/main/resources/JSGenerator.ftl) Freemarker transformer
 
-## Other engine characteristics
+### Other engine characteristics
 
 Some interesting facts for the curious:
 

docs/admin/developer/agama/engine-bridge-config.md

@@ -44,11 +44,6 @@ The properties of Agama engine configuration are described in the following:
 
 - `serializeRules`: A JSON object specifying the serialization rules, see below. It is not recommended to remove items from the out-of-the-box rules. Adding items is fine
 
-<!--
-- `defaultResponseHeaders`: A JSON object : {
-            "Expires": "0"
-        }-->    
-
 ### Serialization rules
 
 At certain points in the course of a flow, serialization of all its variables is required. The engine employs two mechanisms for this purpose: standard Java serialization and [KRYO](https://github.com/EsotericSoftware/kryo) serialization. Depending on the type of (Java) object to be serialized, administrators can specify when a mechanism is preferred over the other through a set of simple rules.

docs/admin/developer/agama/faq.md

@@ -81,7 +81,7 @@ Depending on the package `your` class belongs to, the message may not appear in
 
 Call method `log` of class `io.jans.agama.engine.script.LogUtils`. This method receives a variable number of arguments as DSL's `Log` does. Thus you can do `LogUtils.log("@w Today is Friday %th", 13)`, as in the logging [examples](../../../agama/language-reference.md#logging).
 
-## How to use Contexts and Dependency Injection (CDI)?
+### How to use Contexts and Dependency Injection (CDI)?
 
 Jans server uses Weld (a CDI reference implementation), and as such makes heavy use of managed beans, scopes, dependency injection, events, etc. Unless the code added is part of a jar [library](#how-to-add-third-party-libraries), annotations related to scopes or dependency injection won't take any effect in your code. This is because the Java container does a thorough scanning of classes upon start, but the source code files in `lib` directory are compiled upon use and modification, as expected in a scripting scenario.
 

docs/agama-catalog/jans/inboundID/README.md

@@ -39,7 +39,7 @@ To facilitate administrators' work, the following flows are already implemented:
 
 ### Main flow
 
-The actual process of inbound identity occurs here. This flow is already [implemented](https://github.com/JanssenProject/jans/raw/main/docs/agama-catalog/jans/inboundID/project/io.jans.inbound.ExternalSiteLogin) and ready to use. The following is a summary of the steps involved:
+The actual process of inbound identity occurs here. This flow is already [implemented](https://github.com/JanssenProject/jans/raw/main/docs/agama-catalog/jans/inboundID/project/code/io.jans.inbound.ExternalSiteLogin.flow) and ready to use. The following is a summary of the steps involved:
 
 1. A provider selection page is displayed. The list includes all (*enabled*) providers defined in the configuration of this flow. Additionally an option to use an existing local account is displayed (i.e. no inbound identity)
 
@@ -118,7 +118,7 @@ Edit the file with the properties you consider relevant for every provider. Gene
 
 ### Supply the main flow configurations
 
-The main flow (`io.jans.inbound.ExternalSiteLogin`) has to be parameterized as well. The configuration is held in a JSON object whose keys are the identifiers of the existing identity providers. The associated value for a key is a JSON object itself and follows the structure represented by [this](https://github.com/JanssenProject/jans/blob/vreplace-janssen-version/jans-auth-server/agama/inboundID/src/main/java/io/jans/inbound/Provider.java) Java class.
+The main flow (`io.jans.inbound.ExternalSiteLogin`) has to be parameterized as well. The configuration is held in a JSON object whose keys are the identifiers of the existing identity providers. The associated value for a key is a JSON object itself and follows the structure represented by [this](https://github.com/JanssenProject/jans/blob/main/jans-auth-server/agama/inboundID/src/main/java/io/jans/inbound/Provider.java) Java class.
 
 This is an example of a configuration for a couple of identity providers: