bring back schema isolation on its own page

docs/explanations/db_authz.rst

@@ -92,19 +92,10 @@ You can mix the group and individual role policies. For instance we could still
   -- allow authenticator to switch into user000 role
   -- (the role itself has nologin)
 
-.. _schema_isolation:
-
 Schemas
 =======
 
-A PostgREST instance exposes all the tables, views, and stored procedures of the schemas configured in :ref:`db-schemas`. This means private data or implementation details can go inside private schemas and be invisible to HTTP clients.
-
-It is recommended that you don't expose tables on the schemas you expose, instead expose views and stored procedures which insulate the internal details from the outside world.
-This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning.
-
-.. image:: ../_static/db.png
-
-You must explicitly allow roles to access the exposed schemas:
+You must explicitly allow roles to access the exposed schemas in :ref:`db-schemas`.
 
 .. code-block:: postgres
 

docs/explanations/schema_isolation.rst

@@ -0,0 +1,15 @@
+.. note::
+
+  This page is a work in progress.
+
+.. _schema_isolation:
+
+Schema Isolation
+================
+
+A PostgREST instance exposes all the tables, views, and stored procedures of a single `PostgreSQL schema <https://www.postgresql.org/docs/current/ddl-schemas.html>`_ (a namespace of database objects). This means private data or implementation details can go inside different private schemas and be invisible to HTTP clients.
+
+It is recommended that you don't expose tables on your API schema. Instead expose views and stored procedures which insulate the internal details from the outside world.
+This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning.
+
+.. image:: ../_static/db.png