[FAB-9120] "key/value" -> "key-value" in some doc files

Replace all instances of "key/value" in the docs with the accepted
standard of "key-value" and, while there, might as well fix a few
other grammar issues and typos on those very same lines.

Change-Id: I4c4a0d0c192e212e86151894e7c463a53bd662f9
Signed-off-by: Robert P. J. Day <[email protected]>

docs/source/arch-deep-dive.rst

@@ -81,7 +81,7 @@ support for cross-chaincode transactions (post-v1 feature).*
 ^^^^^^^^^^^^
 
 The latest state of the blockchain (or, simply, *state*) is modeled as a
-versioned key/value store (KVS), where keys are names and values are
+versioned key-value store (KVS), where keys are names and values are
 arbitrary blobs. These entries are manipulated by the chaincodes
 (applications) running on the blockchain through ``put`` and ``get``
 KVS-operations. The state is stored persistently and updates to the
@@ -467,11 +467,11 @@ As a result of the execution, the endorsing peer computes *read version
 dependencies* (``readset``) and *state updates* (``writeset``), also
 called *MVCC+postimage info* in DB language.
 
-Recall that the state consists of key/value (k/v) pairs. All k/v entries
-are versioned, that is, every entry contains ordered version
-information, which is incremented every time when the value stored under
+Recall that the state consists of key-value pairs. All key-value entries
+are versioned; that is, every entry contains ordered version
+information, which is incremented each time the value stored under
 a key is updated. The peer that interprets the transaction records all
-k/v pairs accessed by the chaincode, either for reading or for writing,
+key-value pairs accessed by the chaincode, either for reading or for writing,
 but the peer does not yet update its state. More specifically:
 
 -  Given state ``s`` before an endorsing peer executes a transaction,

docs/source/build_network.rst

@@ -1039,7 +1039,7 @@ The output should display the two marbles owned by ``jerry``:
 
 Why CouchDB
 -------------
-CouchDB is a kind of NoSQL solution. It is a document oriented database where document fields are stored as key-value mpas. Fields can be either a simple key/value pair, list, or map.
+CouchDB is a kind of NoSQL solution. It is a document-oriented database where document fields are stored as key-value maps. Fields can be either a simple key-value pair, list, or map.
 In addition to keyed/composite-key/key-range queries which are supported by LevelDB, CouchDB also supports full data rich queries capability, such as non-key queries against the whole blockchain data,
 since its data content is stored in JSON format and fully queryable. Therefore, CouchDB can meet chaincode, auditing, reporting requirements for many use cases that not supported by LevelDB.
 

docs/source/couchdb_as_state_database.rst

@@ -4,9 +4,9 @@ CouchDB as the State Database
 State Database options
 ----------------------
 
-State database options include LevelDB and CouchDB. LevelDB is the default key/value state
+State database options include LevelDB and CouchDB. LevelDB is the default key-value state
 database embedded in the peer process. CouchDB is an optional alternative external state database.
-Like the LevelDB key/value store, CouchDB can store any binary data that is modeled in chaincode
+Like the LevelDB key-value store, CouchDB can store any binary data that is modeled in chaincode
 (CouchDB attachment functionality is used internally for non-JSON binary data). But as a JSON
 document store, CouchDB additionally enables rich query against the chaincode data, when chaincode
 values (e.g. assets) are modeled as JSON data.

docs/source/ledger.rst

@@ -38,7 +38,7 @@ therefore be regenerated from the chain at any time. The state database will aut
 recovered (or generated if needed) upon peer startup, before transactions are accepted.
 
 State database options include LevelDB and CouchDB. LevelDB is the default state database
-embedded in the peer process and stores chaincode data as key/value pairs. CouchDB is an optional
+embedded in the peer process and stores chaincode data as key-value pairs. CouchDB is an optional
 alternative external state database that provides addition query support when your chaincode data
 is modeled as JSON, permitting rich queries of the JSON content. See
 :doc:`couchdb_as_state_database` for more information on CouchDB.
@@ -49,7 +49,7 @@ Transaction Flow
 At a high level, the transaction flow consists of a transaction proposal sent by an application
 client to specific endorsing peers.  The endorsing peers verify the client signature, and execute
 a chaincode function to simulate the transaction. The output is the chaincode results,
-a set of key/value versions that were read in the chaincode (read set), and the set of keys/values
+a set of key-value versions that were read in the chaincode (read set), and the set of keys/values
 that were written in chaincode (write set). The proposal response gets sent back to the client
 along with an endorsement signature.
 

docs/source/write_first_app.rst

@@ -188,7 +188,7 @@ Querying the Ledger
 -------------------
 
 Queries are how you read data from the ledger. This data is stored as a series
-of key/value pairs, and you can query for the value of a single key, multiple
+of key-value pairs, and you can query for the value of a single key, multiple
 keys, or -- if the ledger is written in a rich data storage format like JSON --
 perform complex searches against it (looking for all assets that contain
 certain keywords, for example).
@@ -235,7 +235,7 @@ It should return something like this:
 
 These are the 10 cars. A black Tesla Model S owned by Adriana, a red Ford Mustang
 owned by Brad, a violet Fiat Punto owned by Pari, and so on. The ledger is
-key/value based and in our implementation the key is ``CAR0`` through ``CAR9``.
+key-value based and, in our implementation, the key is ``CAR0`` through ``CAR9``.
 This will become particularly important in a moment.
 
 Let's take a closer look at this program.  Use an editor (e.g. atom or visual studio)