Merge branch 'fix-typos-in-docs' into improve-documentation

docs/source/index.rst

@@ -7,7 +7,7 @@ BigchainDB Documentation
 Table of Contents
 -----------------
 
-Note to reviewers of this documentation: For now, *all* documentation files (.rst and .md) are  at the same level in the Table of Contents heirarchy. Later, we can organize them into a more sensible heirarchy.
+Note to reviewers of this documentation: For now, *all* documentation files (.rst and .md) are  at the same level in the Table of Contents hierarchy. Later, we can organize them into a more sensible hierarchy.
 
 .. toctree::
    :maxdepth: 5

docs/source/json-serialization.md

@@ -2,7 +2,7 @@
 
 We needed to clearly define how to serialize a JSON object to calculate the hash.
 
-The serialization should produce the same byte output independently of the architecture running the software. If there are diferences in the serialization, hash validations will fail although the transaction is correct.
+The serialization should produce the same byte output independently of the architecture running the software. If there are differences in the serialization, hash validations will fail although the transaction is correct.
 
 For example, consider the following two methods of serializing `{'a': 1}`:
 ```python
@@ -24,7 +24,7 @@ deserialize(serialize(data)) == data
 True
 ```
 
-After looking at this further, we decided that the python json module is still the best bet because it complies with the RFC. We can specify the encoding, separators used and enforce it to order by the keys to make sure that we obtain maximum interopelability.
+After looking at this further, we decided that the python json module is still the best bet because it complies with the RFC. We can specify the encoding, separators used and enforce it to order by the keys to make sure that we obtain maximum interoperability.
 
 ```python
 import json
@@ -35,8 +35,8 @@ json.dumps(data, skipkeys=False, ensure_ascii=False,
 ```
 
 - `skipkeys`: With skipkeys `False` if the provided keys are not a string the serialization will fail. This way we enforce all keys to be strings
-- `ensure_ascii`: The RFC recommends `utf-8` for maximum interoperability. By setting ensure_ascii to `False` we allow unicode characters and force the encoding to `utf-8`.
-- `separators`: We need to define a standard separator to use in the serialization. We did not do this different implementations could use different separators for serialization resulting in a still valid transaction but with a different hash e. g. an extra whitespace introduced in the serialization would not still create a valid json object but the hash would be different.
+- `ensure_ascii`: The RFC recommends `utf-8` for maximum interoperability. By setting `ensure_ascii` to `False` we allow unicode characters and force the encoding to `utf-8`.
+- `separators`: We need to define a standard separator to use in the serialization. We did not do this different implementations could use different separators for serialization resulting in a still valid transaction but with a different hash e.g. an extra whitespace introduced in the serialization would not still create a valid JSON object but the hash would be different.
 
 Every time we need to perform some operation on the data like calculating the hash or signing/verifying the transaction, we need to use the previous criteria to serialize the data and then use the `byte` representation of the serialized data (if we treat the data as bytes we eliminate possible encoding errors e.g. unicode characters). For example:
 ```python
@@ -52,4 +52,4 @@ signature = sk.sign(tx_serialized)
 # verify signature
 tx_serialized = bytes(serialize(tx))
 vk.verify(signature, tx_serialized)
-```
+```

docs/source/models.md

@@ -35,7 +35,7 @@ This can be changed in the future to allow multiple inputs per transaction.
 - `operation`: String representation of the operation being performed (REGISTER, TRANSFER, ...) this will define how
 the transactions should be validated
 - `timestamp`: Time of creation of the transaction in UTC
-- `data`: Json object describing the asset (digital content). It contains at least the field `hash` which is a 
+- `data`: JSON object describing the asset (digital content). It contains at least the field `hash` which is a 
 sha3 hash of the digital content.
 - `signature`: ECDSA signature of the transaction with the `current_owner` private key
 
@@ -59,7 +59,7 @@ Still to be defined when new blocks are created (after x number of transactions,
 or both).
 A block contains a group of transactions and includes the hash of the hash of the previous block to build the chain.
 
-- `id`: sha3 hash of the current block. This is also a rethinkdb primary key, this way we make sure that all blocks are unique.
+- `id`: sha3 hash of the current block. This is also a RethinkDB primary key, this way we make sure that all blocks are unique.
 - `block`: The actual block
     - `timestamp`: timestamp when the block was created
     - `transactions`: the list of transactions included in the block

docs/source/release-notes.md

@@ -1,3 +1,3 @@
 # Release Notes
 
-This section has the release notes for each version of BigChainDB.
+This section has the release notes for each version of BigchainDB.