Apply suggestions from code review

Co-authored-by: Alex Aperis <[email protected]>
neicnordic · Nov 30, 2023 · 2fe2d67 · 2fe2d67
1 parent f1fbf8a
commit 2fe2d67
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 3 deletions.
diff --git a/docs/connection.md b/docs/connection.md
@@ -7,7 +7,7 @@ components to send and receive messages, which are queued, not lost, and
 resent on network failure or connection problems.
 
 The RabbitMQ message brokers of each SDA instance are the **only**
-components with the necessary credentials to connect to CentralEGA
+components with the necessary credentials to connect to `CentralEGA`
 message broker.
 
 We call `CEGAMQ` and `LocalMQ` (Local Message Broker, sometimes know as `sda-mq`), 
@@ -136,7 +136,7 @@ and the shovel mechanism in their local broker.
 instance, on the given `vhost`.
 
 The exchanges and routing keys will be the same as all the other
-FederatedEGA instances, since the clustering is done per `vhost`.
+`FederatedEGA` instances, since the clustering is done per `vhost`.
 
 ### Message Format
 

diff --git a/docs/structure.md b/docs/structure.md
@@ -18,7 +18,7 @@ In a Federated setup, the `FederatedEGA` archive node setup locally need to exch
 
 In a stand-alone setup, the deployed service has less remote synchronisation to worry about, but on the other hand more components might be required (e.g ([orchestrator](services/orchestrator))) to also handle annotations/meta-data locally, as well as to deal with identifiers etc.
 
-The NeIC SDA is targeting both types of setup, to open up the use of the re-use of components to more use cases than initially envisioned.
+The NeIC SDA is targeting both types of setup but also to allow for the possibility to re-use components in more use cases than initially envisioned.
 
 
 ### Container deployment options