Apply suggestions from code review

Co-authored-by: per1234 <[email protected]>

Author: cmaglie

docs/package_index_json-specification.md

@@ -81,7 +81,7 @@ Each tool describes a binary distribution of a command line tool. A tool can be:
 - a debugger
 - a program that performs a firmware upgrade
 - a [pluggable discovery](pluggable-discovery-specification.md)
-- a [pluggable monitor][pluggable-monitor-specification.md]
+- a [pluggable monitor](pluggable-monitor-specification.md)
 
 basically anything that can run on the user's host PC and do something useful.
 

docs/platform-specification.md

@@ -762,20 +762,20 @@ Monitor tools are a special kind of tool used to let the user communicate with t
 A platform must declare one or more Pluggable Monitor in its [`platform.txt`](#platformtxt) and bind them to a specific
 port protocol. Monitors can be referenced from other packages.
 
-The following direcive is used to bind a specific monitor tool to a specific port protocol:
+The following directive is used to bind a specific monitor tool to a specific port protocol:
 
 ```
-pluggable_monitor.required.PROTOCOL=PLATFORM:MONITOR_NAME
+pluggable_monitor.required.PROTOCOL=VENDOR_ID:MONITOR_NAME
 ```
 
-where `PROTOCOL` must be replaced with the port protocol identifier and `PLATFORM:MONITOR_NAME` must be replaced with
+where `PROTOCOL` must be replaced with the port protocol identifier and `VENDOR_ID:MONITOR_NAME` must be replaced with
 the monitor tool identifier.
 
 The platform can support as many protocols as needed:
 
 ```
-pluggable_monitor.required.PROTOCOL1=PLATFORM:MONITOR_NAME1
-pluggable_monitor.required.PROTOCOL2=PLATFORM:MONITOR_NAME2
+pluggable_monitor.required.PROTOCOL1=VENDOR_ID:MONITOR_NAME1
+pluggable_monitor.required.PROTOCOL2=VENDOR_ID:MONITOR_NAME2
 ...
 ```
 
@@ -794,10 +794,10 @@ example could be:
 pluggable_monitor.pattern.custom-ble="{runtime.tools.my-ble-monitor.path}/my-ble-monitor" -H
 ```
 
-in this case the platform provides a new hypotetical `custom-ble` protocol monitor tool and the command line tool named
+in this case the platform provides a new hypothetical `custom-ble` protocol monitor tool and the command line tool named
 `my-ble-monitor` is launched with the `-H` parameter to start the monitor tool. In this case the command line pattern
 may contain any extra parameter in the formula: this is different from the monitor tools installed through the
-`discoveryDependencies` field that must run without any command line parameter.
+`monitorDependencies` field that must run without any command line parameter.
 
 We strongly recommend using this syntax only for development purposes and not on released platforms.
 

docs/pluggable-discovery-specification.md

@@ -43,7 +43,7 @@ the response to the command is:
 The `protocolVersion` field represents the protocol version that will be used in the rest of the communication. There
 are three possible cases:
 
-- if the client/IDE supports the same or a more recent version of the protocol than the discovery, then the clietn/IDE
+- if the client/IDE supports the same or a more recent version of the protocol than the discovery, then the client/IDE
   should go into a compatibility mode and use the protocol level supported by the discovery.
 - if the discovery supports a more recent version of the protocol than the client/IDE: the discovery should downgrade
   itself into compatibility mode and report a `protocolVersion` that is less than or equal to the one supported by the

docs/pluggable-monitor-specification.md

@@ -128,7 +128,7 @@ The response to the command is:
 ```JSON
 {
   "event": "configure",
-  "message": "ok",
+  "message": "ok"
 }
 ```
 
@@ -155,13 +155,13 @@ tool as part of the `OPEN` command. The syntax of the `OPEN` command is:
 `OPEN <CLIENT_TCPIP_ADDRESS> <BOARD_PORT>`
 
 For example, let's suppose that the Client/IDE wants to communicate with the serial port `/dev/ttyACM0` using an
-hypotetical `serial-monitor` tool, then the sequence of actions to perform will be the following:
+hypothetical `serial-monitor` tool, then the sequence of actions to perform will be the following:
 
 1. the Client/IDE must first listen to a random TCP port (let's suppose it chose `32123`)
-1. the Client/IDE runs the `serial-monitor` tool and initialize it with the `HELLO` command
+1. the Client/IDE runs the `serial-monitor` tool and initializes it with the `HELLO` command
 1. the Client/IDE sends the command `OPEN 127.0.0.1:32123 /dev/ttyACM0` to the monitor tool
 1. the monitor tool opens `/dev/ttyACM0`
-1. the monitor tool connects via TCP/IP to `127.0.0.1:32123` and start streaming data back and forth
+1. the monitor tool connects via TCP/IP to `127.0.0.1:32123` and starts streaming data back and forth
 
 The answer to the `OPEN` command is:
 
@@ -186,7 +186,7 @@ other error condition happens:
 The board port will be opened using the parameters previously set through the `CONFIGURE` command.
 
 Once the port is opened, it may be unexpectedly closed at any time due to hardware failure, or because the Client/IDE
-closes the TCP/IP connection, etc. In this case an asynchronous `port_closed` message must be generated from the monitor
+closes the TCP/IP connection, etc. In this case an asynchronous `port_closed` message must be generated by the monitor
 tool:
 
 ```JSON
@@ -238,7 +238,7 @@ The `QUIT` command terminates the monitor. The response to `QUIT` is:
 }
 ```
 
-after this output the monitor exits. This command is supposed to always succeed.
+after this output the monitor exits. This command must always succeed.
 
 #### Invalid commands