Fix policy.json reference format issue

The patch fix oxford comma issue, capitalizing the first letter
in bullets, and change the code block format from none to json.

Change-Id: I0bf975e236aadd60a84b06ed66f1c8f4a8910606
Co-Authored-By: Kevin_Zheng <zhengzhenyu@huawei.com>
Related-Bug: #1575926

doc/config-reference/source/policy-json-file.rst

@@ -2,7 +2,7 @@
 The policy.json file
 ====================
 
-Each OpenStack service, Identity, Compute, Networking and so on, has its
+Each OpenStack service, Identity, Compute, Networking, and so on, has its
 own role-based access policies. They determine which user can access
 which objects in which way, and are defined in the service's
 ``policy.json`` file.
@@ -20,10 +20,10 @@ form ``"<target>" : "<rule>"``.
 The policy target, also named "action", represents an API call like
 "start an instance" or "attach a volume".
 
-Action names are usually qualified. Example: OpenStack Compute features
-API calls to list instances, volumes and networks. In
+Action names are usually qualified. For example, the Compute service features
+API calls to list instances, volumes, and networks. In
 ``/etc/nova/policy.json``, these APIs are represented by
-``compute:get_all``, ``volume:get_all`` and ``network:get_all``,
+``compute:get_all``, ``volume:get_all``, and ``network:get_all``,
 respectively.
 
 The mapping between API calls and actions is not generally documented.
@@ -63,7 +63,7 @@ You can also decline permission to use an API:
 The exclamation mark stands for "never" or "nobody", which effectively
 disables the Compute API "shelve an instance".
 
-Many APIs can only be called by admin users. This can be expressed by
+Many APIs can only be called by administrators. This can be expressed by
 the rule ``"role:admin"``. The following policy ensures that only
 administrators can create new users in the Identity database:
 
@@ -72,7 +72,7 @@ administrators can create new users in the Identity database:
     "identity:create_user" : "role:admin"
 
 You can limit APIs to any role. For example, the Orchestration service
-defines a role named ``heat_stack_user``. Whoever has this role isn't
+defines a role named ``heat_stack_user``. Whoever has this role is not
 allowed to create stacks:
 
 .. code-block:: none
@@ -80,7 +80,7 @@ allowed to create stacks:
     "stacks:create": "not role:heat_stack_user"
 
 This rule makes use of the boolean operator ``not``. More complex rules
-can be built using operators ``and``, ``or`` and parentheses.
+can be built using operators ``and``, ``or``, and parentheses.
 
 You can define aliases for rules:
 
@@ -107,11 +107,11 @@ Rules can compare API attributes to object attributes. For example:
 states that only the owner of an instance can start it up. The
 ``project_id`` string before the colon is an API attribute, namely the project
 ID of the API user. It is compared with the project ID of the object (in
-this case, an instance); more precisely, it is compared with the
+this case, an instance). More precisely, it is compared with the
 ``project_id`` field of that object in the database. If the two values are
 equal, permission is granted.
 
-An admin user always has permission to call APIs. This is how
+An administrator always has permission to call APIs. This is how
 ``/etc/keystone/policy.json`` makes this policy explicit:
 
 .. code-block:: none
@@ -187,7 +187,7 @@ Rules can be:
 
 -  boolean expressions based on simpler rules
 
-Special checks are
+Special checks are:
 
 -  ``<role>:<role name>``, a test whether the API credentials contain
    this role.
@@ -205,7 +205,7 @@ Two values are compared in the following way:
 
     "value1 : value2"
 
-Possible values are
+Possible values are:
 
 -  constants: Strings, numbers, ``true``, ``false``
 
@@ -221,11 +221,11 @@ Target object attributes are fields from the object description in the
 database. For example in the case of the ``"compute:start"`` API, the
 object is the instance to be started. The policy for starting instances
 could use the ``%(project_id)s`` attribute, that is the project that
-owns the instance. The trailing s indicates this is a string.
+owns the instance. The trailing ``s`` indicates this is a string.
 
 ``is_admin`` indicates that administrative privileges are granted via
 the admin token mechanism (the ``--os-token`` option of the ``keystone``
-command). The admin token allows initialisation of the identity database
+command). The admin token allows initialisation of the Identity database
 before the admin role exists.
 
 The alias construct exists for convenience. An alias is short name for a