DOCS-653: edits in response to reviews from kevin m.

Author: Sam Kleinman

source/core/capped-collections.txt

@@ -14,8 +14,8 @@ by overwriting the oldest documents in the collection.
 Capped collections have the following behaviors:
 
 - Capped collections guarantee preservation of the insertion order. As
-  a result, queries do not need an index to return documents ordered
-  by the insertion order. Without this indexing overhead, they can
+  a result, queries do not need an index to return documents in
+  insertion order. Without this indexing overhead, they can
   support higher insertion throughput.
 
 - Capped collections guarantee that insertion order is identical to the
@@ -33,7 +33,7 @@ collection. Consider the following potential uses cases for capped
 collections:
 
 - Store log information generated by high-volume systems. Inserting
-  documents in an capped collection without an index is close to the
+  documents in a capped collection without an index is close to the
   speed of writing log information directly to a file
   system. Furthermore, the built-in *first-in-first-out* property
   maintains the order of events, while managing storage use.
@@ -49,33 +49,36 @@ Recommendations and Restrictions
 
 - You cannot shard a capped collection.
 
-- Only capped collections created after 2.2 have an ``_id`` field and
-  indexes on the ``_id`` field. Capped collections created before 2.2
-  do indexes on the ``_id`` by default.
+- Capped collections created after 2.2 have an ``_id`` field and an
+  index on the ``_id`` field by default. Capped collections created
+  before 2.2 do not have an index on the ``_id`` field by default. If
+  you are using capped collections with replication prior to 2.2, you
+  should explicitly create an index on the ``_id`` field.
 
 - You *can* update documents in a collection after inserting them;
   *however*, these updates *cannot* cause the documents to grow. If the
-  update operation causes the document to grow, the update operation
-  will fail.
+  update operation causes the document to grow beyond their original
+  size, the update operation will fail.
 
   If you plan to update documents in a capped
   collection, remember to create an index to prevent update
   operations that require a table scan.
 
 - You cannot delete documents from a capped collection. To remove all
-  records from the collection, use the :dbcommand:`emptycapped`
-  command.
+  records from a capped collection, use the 'emptycapped' command. To
+  remove the collection entirely, use the :method:`drop()
+  <db.collection.drop()>` method.
 
 .. warning::
 
    If you have a capped collection in a :term:`replica set` outside of
    the ``local`` database, before 2.2, you should create a unique
    index on ``_id``.  Ensure uniqueness using the ``unique: true``
    option to the :method:`ensureIndex() <db.collection.ensureIndex()>`
-   by using an :term:`ObjectId` for the ``_id`` field use the
-   ``autoIndexId`` option to :dbcommand:`createCollection` when
-   creating the capped collection, as in the
-   :ref:`capped-collections-options` procedure.
+   method or by using an :term:`ObjectId` for the ``_id``
+   field. Alternately, you can use the ``autoIndexId`` option to
+   :dbcommand:`createCollection` when creating the capped collection,
+   as in the :ref:`capped-collections-options` procedure.
 
 - Use natural ordering to retrieve the most recently inserted elements
   from the collection efficiently. This is (somewhat) analogous to