[FAB-3906] Fix build errors in the doc.

Fix all the markup errors reported by 'make html' $ cd docs $ make clean $ make html >make.log 2>&1 $ grep ERROR make.log $ Rebased and Fixed a newly introduced error. Change-Id: I9b01167d2782062e82156607b083945cf86b938a Signed-off-by: Arnaud J Le Hors <lehors@us.ibm.com>
hyperledger · Jun 6, 2017 · dc0dfe3 · dc0dfe3
1 parent 1cdbfc0
commit dc0dfe3
Show file tree

Hide file tree

Showing 7 changed files with 48 additions and 45 deletions.
diff --git a/docs/source/FAQ/confidentiality_FAQ.rst b/docs/source/FAQ/confidentiality_FAQ.rst
@@ -1,7 +1,7 @@
 Confidentiality
 ===============
 
- * How is the confidentiality of transactions and business logic achieved?
+* How is the confidentiality of transactions and business logic achieved?
 
 The security module works in conjunction with the membership service
 module to provide access control service to any data recorded and
@@ -18,8 +18,7 @@ the contents of confidential transactions are encrypted with secret keys
 known only to their originators, validators, and authorized auditors.
 Only holders of the secret keys can interpret transaction contents.
 
-* What if none of the stakeholders of a business contract are
-validators?
+* What if none of the stakeholders of a business contract are validators?
 
 In some business scenarios, full confidentiality of contract
 logic may be required – such that only contract counterparties and

diff --git a/docs/source/FAQ/identity_management_FAQ.rst b/docs/source/FAQ/identity_management_FAQ.rst
@@ -22,8 +22,7 @@ Like most other modules on Fabric, you can always replace the
 default module with another membership service option should the need
 arise.
 
-* Does its Membership Service make Fabric a centralized
-solution?
+* Does its Membership Service make Fabric a centralized solution?
 
 No. The only role of the Membership Service module is to issue digital
 certificates to validated entities that want to participate in the

diff --git a/docs/source/FAQ/usage_FAQ.rst b/docs/source/FAQ/usage_FAQ.rst
@@ -19,7 +19,7 @@ In addition, NV-nodes retain full copies of the ledger, enabling local
 queries of the ledger data.
 
 * What does the error string "state may be inconsistent, cannot
-query" as a query result mean?
+  query" as a query result mean?
 
 Sometimes, a validating peer will be out
 of sync with the rest of the network. Although determining this

diff --git a/docs/source/abstract_v1.rst b/docs/source/abstract_v1.rst
@@ -36,47 +36,51 @@ regulatory statutes.
 WHERE WE'RE GOING
 -----------------
 
-| The new architecture introduces a clear functional separation of peer
-  roles, and allows a transaction to pass through the network in a
-  structured and modularized fashion.
-| The peers are diverged into two distinct roles – Endorser & Committer.
-  As an endorser, the peer will simulate the transaction and ensure that
-  the outcome is both deterministic and stable. As a committer, the peer
-  will validate the integrity of a transaction and then append to the
-  ledger. Now confidential transactions can be sent to specific
-  endorsers and their correlating committers, without the broader
-  network being made cognizant of the transaction. Additionally,
-  policies can be set to determine what levels of “endorsement” and
-  “validation” are acceptable for a specific class of transactions.
-| A failure to meet these thresholds would simply result in a
-  transaction being withdrawn or labeled as "invalid", rather than
-  imploding or stagnating the entire network.
-| This new model also introduces the possibility for more elaborate
-  networks, such as a foreign exchange market. For example, trade
-  settlement might be contingent upon a mandatory "endorsement" from a
-  trusted third party (e.g. a clearing house).
-
-| The consensus or "ordering" process (i.e. algorithmic computation) is
-  entirely abstracted from the peer. This modularity not only provides a
-  powerful security layer – the ordering nodes are agnostic to the
-  transaction logic – but it also generates a framework where ordering
-  can become a pluggable implementation and scalability can truly occur.
-| There is no longer a parallel relationship between the number of peers
-  in a network and the number of orderers. Now networks can grow
-  dynamically (i.e. add endorsers and committers) without having to add
-  corresponding orderers, all the while existing in a modular
-  infrastructure designed to support high transaction throughput.
-  Moreover, networks now have the capability to completely liberate
-  themselves from the computational and legal burden of ordering by
-  tapping into a pre-existing or third party-hosted "ordering service."
+The new architecture introduces a clear functional separation of peer
+roles, and allows a transaction to pass through the network in a
+structured and modularized fashion.
+
+The peers are diverged into two distinct roles – Endorser & Committer.
+As an endorser, the peer will simulate the transaction and ensure that
+the outcome is both deterministic and stable. As a committer, the peer
+will validate the integrity of a transaction and then append to the
+ledger. Now confidential transactions can be sent to specific
+endorsers and their correlating committers, without the broader
+network being made cognizant of the transaction. Additionally,
+policies can be set to determine what levels of “endorsement” and
+“validation” are acceptable for a specific class of transactions.
+
+A failure to meet these thresholds would simply result in a
+transaction being withdrawn or labeled as "invalid", rather than
+imploding or stagnating the entire network.
+
+This new model also introduces the possibility for more elaborate
+networks, such as a foreign exchange market. For example, trade
+settlement might be contingent upon a mandatory "endorsement" from a
+trusted third party (e.g. a clearing house).
+
+The consensus or "ordering" process (i.e. algorithmic computation) is
+entirely abstracted from the peer. This modularity not only provides a
+powerful security layer – the ordering nodes are agnostic to the
+transaction logic – but it also generates a framework where ordering
+can become a pluggable implementation and scalability can truly occur.
+
+There is no longer a parallel relationship between the number of peers
+in a network and the number of orderers. Now networks can grow
+dynamically (i.e. add endorsers and committers) without having to add
+corresponding orderers, all the while existing in a modular
+infrastructure designed to support high transaction throughput.
+Moreover, networks now have the capability to completely liberate
+themselves from the computational and legal burden of ordering by
+tapping into a pre-existing or third party-hosted "ordering service."
 
 As v1.0 manifests, we will see the foundation for interoperable
 blockchain networks that have the ability to scale and transact in a
 manner adherent with regulatory and industry standards. Watch how fabric
 v1.0 and the Hyperledger Project are building a true blockchain for
-business -
+business.
 
-|HYPERLEDGERv1.0\_ANIMATION|
+|FabricV1.0Animation|
 
 HOW TO CONTRIBUTE
 -----------------
@@ -104,8 +108,8 @@ that will spawn the capabilities in v1.0:
 -  Explore the
    `documentation <http://hyperledger-fabric.readthedocs.io/en/latest/>`__
 
-.. |HYPERLEDGERv1.0\_ANIMATION| image:: http://img.youtube.com/vi/EKa5Gh9whgU/0.jpg
-   :target: http://www.youtube.com/watch?v=EKa5Gh9whgU
+.. |FabricV1.0Animation| image:: https://img.youtube.com/vi/EKa5Gh9whgU/0.jpg
+   :target: https://www.youtube.com/watch?v=EKa5Gh9whgU
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

diff --git a/docs/source/best_practices.rst b/docs/source/best_practices.rst
@@ -1,5 +1,5 @@
 Best Practices
-===========
+==============
 
 Coming soon...
 

diff --git a/docs/source/configtx.rst b/docs/source/configtx.rst
@@ -136,7 +136,7 @@ we use the golang map reference syntax, so
 
 * ``policy1`` maps to ``Channel.Groups["Application"].Policies["policy1"]``
 * ``Org1/policy2`` maps to
-``Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]``
+  ``Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]``
 * ``/Channel/policy3`` maps to ``Channel.Policies["policy3"]``
 
 Note that if a ``mod_policy`` references a policy which does not exist,

diff --git a/docs/source/getting_started.rst b/docs/source/getting_started.rst
@@ -236,6 +236,7 @@ However, if you want to see this script in action, delete your crypto material
 and channel artifacts with the following command:
 
 .. code:: bash
+
     ./network_setup.sh down
 
 Now proceed...