Address final VDR feedbacks (#2332)

* Address final VDR feedbacks

* Fix typo

* Address feedback

docs/examples/fl_experiment_tracking_mlflow.rst

@@ -53,10 +53,10 @@ Adding MLflow Logging to Configurations
 
 Inside the config folder there are two files, ``config_fed_client.json`` and ``config_fed_server.json``.
 
-.. literalinclude:: ../../examples/advanced/experiment-tracking/mlflow/jobs/hello-pt-mlflow/app/config/config_fed_client.json
-   :language: json
+.. literalinclude:: ../../examples/advanced/experiment-tracking/mlflow/jobs/hello-pt-mlflow/app/config/config_fed_client.conf
+   :language:
    :linenos:
-   :caption: config_fed_client.json
+   :caption: config_fed_client.conf
 
 Take a look at the components section of the client config at line 24.
 The first component is the ``pt_learner`` which contains the initialization, training, and validation logic.
@@ -69,10 +69,10 @@ within NVFlare with the information to track.
 Finally, :class:`ConvertToFedEvent<nvflare.app_common.widgets.convert_to_fed_event.ConvertToFedEvent>` converts local events to federated events.
 This changes the event ``analytix_log_stats`` into a fed event ``fed.analytix_log_stats``, which will then be streamed from the clients to the server.
 
-.. literalinclude:: ../../examples/advanced/experiment-tracking/mlflow/jobs/hello-pt-mlflow/app/config/config_fed_server.json
-   :language: json
+.. literalinclude:: ../../examples/advanced/experiment-tracking/mlflow/jobs/hello-pt-mlflow/app/config/config_fed_server.conf
+   :language:
    :linenos:
-   :caption: config_fed_server.json
+   :caption: config_fed_server.conf
 
 Under the component section in the server config, we have the
 :class:`MLflowReceiver<nvflare.app_opt.tracking.mlflow.mlflow_receiver.MLflowReceiver>`. This component receives

docs/programming_guide.rst

@@ -37,6 +37,7 @@ Please refer to :ref:`application` for more details.
 
    programming_guide/workflows_and_controllers
    programming_guide/execution_api_type
+   programming_guide/fl_model
    programming_guide/shareable
    programming_guide/data_exchange_object
    programming_guide/fl_context

docs/programming_guide/execution_api_type.rst

@@ -1,11 +1,12 @@
 .. _execution_api_type:
 
-##################
-Execution API Type
-##################
+#######################
+From Local to Federated
+#######################
 
 In the FLARE system, a federated learning algorithm is defined in a Job format
 (for details, please refer to :ref:`job`).
+
 A Job consists of multiple "workflows" and "executors."
 
 The simplified job execution flow is as follows:
@@ -16,25 +17,31 @@ The simplified job execution flow is as follows:
 - If it is not done, it schedules a new task
 - If it is done, it proceeds to the next workflow in the Job.
 
-Users need to adapt their local training logic into FLARE's task execution
-abstractions to make their training federated.
+Users need to adapt their local training or computing logic into FLARE's task
+execution abstractions to make their training or computing federated.
 
 We offer various levels of abstraction for writing task execution code,
 catering to use cases that span from complete customizability to easy user adaptation.
 
+Execution API Type
+==================
+
 Below is a general overview of the key ideas and use cases for each type:
 
-**Client API**
+Client API
+----------
 
 The :ref:`client_api` provides the most straightforward way to write FL code,
 and can easily be used to convert centralized code with minimal code changes.
 The Client API uses the :class:`FLModel<nvflare.app_common.abstract.fl_model.FLModel>`
 object for data transfer and supports common tasks such as train, validate, and submit_model.
 Additionally, options for using decorators or PyTorch Lightning are also available.
 
-We recommend users start with the Client API, and to consider the other types for more specific cases as required.
+We recommend users start with the Client API, and to consider the other types
+for more specific cases as required.
 
-**ModelLearner**
+ModelLearner
+------------
 
 The :ref:`model_learner` is designed to simplify writing learning logic by
 minimizing FLARE-specific concepts.
@@ -49,7 +56,8 @@ The ModelLearner is best used when working with standard machine learning code
 that can fit well into the train and validate methods and can be easily adapted
 to the ModelLearner subclass and method structure.
 
-**Executor**
+Executor
+--------
 
 :ref:`executor` is the most flexible for defining custom logic and tasks,
 as with a custom executor and controller, any form of computation can be performed.
@@ -62,7 +70,8 @@ abstract these concepts away for easier user adaptation.
 Overall, writing an Executor is most useful when implementing tasks and logic
 that do not fit within the structure of higher-level APIs or other predefined Executors.
 
-**3rd-Party System Integration**
+3rd-Party System Integration
+----------------------------
 
 There are cases where users have a pre-existing ML/DL training system
 infrastructure that cannot be easily adapted to the FLARE client.