diff --git a/docs/specs/spec-meta-deposit.rst b/docs/specs/spec-meta-deposit.rst
index a4f700c8..517757fc 100644
--- a/docs/specs/spec-meta-deposit.rst
+++ b/docs/specs/spec-meta-deposit.rst
@@ -1,100 +1,84 @@
 The metadata-deposit
 ====================
 
 Goal
 ----
 A client wishes to deposit only metadata about an object in the Software
 Heritage archive.
 
 The meta-deposit is a special deposit where no content is
-deposited and the data transfered to Software Heritage is only
+provided and the data transfered to Software Heritage is only
 the metadata about an object or several objects in the archive.
 
+Requirements
+------------
 The scope of the meta-deposit is different than the
-sparse-deposit, while a sparse-deposit creates a revision with referenced
+sparse-deposit. While a sparse-deposit creates a revision with referenced
 directories and content files, the meta-deposit references one of the following:
 
 - origin
 - snapshot
 - revision
 - release
 
 
 A complete metadata example
 ---------------------------
 The reference element is included in the metadata xml atomEntry under the
 swh namespace:
 
 .. code:: xml
 
   <?xml version="1.0"?>
     <entry xmlns="http://www.w3.org/2005/Atom"
              xmlns:codemeta="https://doi.org/10.5063/SCHEMA/CODEMETA-2.0"
              xmlns:swh="swh.xsd">
         <author>
           <name>HAL</name>
           <email>hal@ccsd.cnrs.fr</email>
         </author>
         <client>hal</client>
         <external_identifier>hal-01243573</external_identifier>
         <codemeta:name>The assignment problem</codemeta:name>
         <codemeta:url>https://hal.archives-ouvertes.fr/hal-01243573</codemeta:url>
         <codemeta:identifier>other identifier, DOI, ARK</codemeta:identifier>
         <codemeta:applicationCategory>Domain</codemeta:applicationCategory>
         <codemeta:description>description</codemeta:description>
         <codemeta:author>
             <codemeta:name> author1 </codemeta:name>
             <codemeta:affiliation> Inria </codemeta:affiliation>
             <codemeta:affiliation> UPMC </codemeta:affiliation>
         </codemeta:author>
         <codemeta:author>
             <codemeta:name> author2 </codemeta:name>
             <codemeta:affiliation> Inria </codemeta:affiliation>
             <codemeta:affiliation> UPMC </codemeta:affiliation>
         </codemeta:author>
         <swh:deposit>
           <swh:reference>
             <swh:origin url='https://github.com/user/repo'/>
           </swh:reference>
         </swh:deposit>
     </entry>
 
-examples by target type
+Examples by target type
 ^^^^^^^^^^^^^^^^^^^^^^^
-snapshot
-*********
-.. code:: xml
 
-  <swh:deposit>
-    <swh:reference>
-      <swh:object id="swh:1:snp:aaaaaaaaaaaaaa..."/>
-    </swh:reference>
-  </swh:deposit>
+With ${type} in {snp (snapshot), rev (revision), rel (release) }:
 
-revision
-********
 .. code:: xml
 
   <swh:deposit>
     <swh:reference>
-      <swh:object id="swh:1:rev:aaaaa............"/>
+      <swh:object id="swh:1:${type}:aaaaaaaaaaaaaa..."/>
     </swh:reference>
   </swh:deposit>
 
-release
-*******
-.. code:: xml
 
-  <swh:deposit>
-    <swh:reference>
-      <swh:object id="swh:1:rel:aaaaaaaaaaaaaa...."/>
-    </swh:reference>
-  </swh:deposit>
 
 Loading procedure
 ------------------
 
 In this case, the meta-deposit will be injected as a metadata entry at the
-appropriate level (origin_metadata, revision_metadata, etc.) and won't result
-in  the creation of a new object like with the complete deposit and the
-sparse-deposit.
+appropriate level (origin_metadata, revision_metadata, etc.). Contrary to the
+complete and sparse deposit, there will be no object creation.
diff --git a/docs/specs/spec-sparse-deposit.rst b/docs/specs/spec-sparse-deposit.rst
index 6fd12f5c..e08f5728 100644
--- a/docs/specs/spec-sparse-deposit.rst
+++ b/docs/specs/spec-sparse-deposit.rst
@@ -1,104 +1,101 @@
 The sparse-deposit
 ==================
 
 Goal
 ----
 A client wishes to transfer a tarball for which part of the content is
 already in the SWH archive.
 
 Requirements
 ------------
-To do so, the paths to the missing directories/content must be provided as
-empty paths in the tarball and the list linking each path to the object in the
-archive will be provided as part of the metadata. The list will be refered to
-as the manifest list.
+To do so, a list of paths with targets must be provided in the metadata and
+the paths to the missing directories/content should not be included
+in the tarball. The list will be referred to
+as the manifest list using the entry name 'bindings' in the metadata.
 
 +----------------------+-------------------------------------+
 | path                 | swh-id                              |
 +======================+=====================================+
 | path/to/file.txt     |  swh:1:cnt:aaaaaaaaaaaaaaaaaaaaa... |
 +----------------------+-------------------------------------+
 | path/to/dir/         |  swh:1:dir:aaaaaaaaaaaaaaaaaaaaa... |
 +----------------------+-------------------------------------+
 
 Note: the *name* of the file or the directory is given by the path and is not
 part of the identified object.
 
 A concrete example
 ------------------
 The manifest list is included in the metadata xml atomEntry under the
 swh namespace:
 
 .. code:: xml
 
   <?xml version="1.0"?>
     <entry xmlns="http://www.w3.org/2005/Atom"
              xmlns:codemeta="https://doi.org/10.5063/SCHEMA/CODEMETA-2.0"
              xmlns:swh="swh.xsd">
         <author>
           <name>HAL</name>
           <email>hal@ccsd.cnrs.fr</email>
         </author>
         <client>hal</client>
         <external_identifier>hal-01243573</external_identifier>
         <codemeta:name>The assignment problem</codemeta:name>
         <codemeta:url>https://hal.archives-ouvertes.fr/hal-01243573</codemeta:url>
         <codemeta:identifier>other identifier, DOI, ARK</codemeta:identifier>
         <codemeta:applicationCategory>Domain</codemeta:applicationCategory>
         <codemeta:description>description</codemeta:description>
         <codemeta:author>
             <codemeta:name> author1 </codemeta:name>
             <codemeta:affiliation> Inria </codemeta:affiliation>
             <codemeta:affiliation> UPMC </codemeta:affiliation>
         </codemeta:author>
         <codemeta:author>
             <codemeta:name> author2 </codemeta:name>
             <codemeta:affiliation> Inria </codemeta:affiliation>
             <codemeta:affiliation> UPMC </codemeta:affiliation>
         </codemeta:author>
         <swh:deposit>
           <swh:bindings>
           <swh:binding source="path/to/file.txt"
                        destination="swh:1:cnt:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"/>
           <swh:binding source="path/to/second_file.txt
                        destination="swh:1:cnt:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"/>
           <swh:binding source="path/to/dir/
                        destination="swh:1:dir:ddddddddddddddddddddddddddddddddd"/>
 
         </swh:bindings>
         </swh:deposit>
     </entry>
 
-The tarball sent with the deposit will contain the following empty paths:
-- path/to/file.txt
-- path/to/second_file.txt
-- path/to/dir/
 
 Deposit verification
 --------------------
 
 After checking the integrity of the deposit content and
 metadata, the following checks should be added:
 
-1. validate the manifest list structure with a swh-id for each path
-2. verify that the paths in the manifest list are explicit and empty in the tarball
-3. verify that the path name corresponds to the object type
-4. locate the identifiers in the SWH archive
+1. validate the manifest list structure with a correct swh-id for each path  (syntax check on the swh-id format)
+2. verify that the path name corresponds to the object type
+3. locate the identifiers in the SWH archive
 
-Each one of the verifications should return a different error with the deposit
+Each failing check should return a different error with the deposit
 and result in a 'rejected' deposit.
 
 Loading procedure
 ------------------
 The injection procedure should include:
 
-- load the tarball data
+- load the tarball new data
 - create new objects using the path name and create links from the path to the
   SWH object using the identifier
 - calculate identifier of the new objects at each level
 - return final swh-id of the new revision
 
-Invariant: the same content should yield the same swhid, that's why a complete
-deposit with all the content and a sparse-deposit with the correct links will
-result with the same root directory swh-id and if the metadata are identical
-also with the same revision swh-id.
+Invariant: the same content should yield the same swh-id,
+that's why a complete deposit with all the content and
+a sparse-deposit with the correct links will result
+with the same root directory swh-id.
+The same is expected with the revision swh-id if the metadata provided is
+identical.
diff --git a/docs/specs/specs.rst b/docs/specs/specs.rst
index 608183c4..bb86993d 100644
--- a/docs/specs/specs.rst
+++ b/docs/specs/specs.rst
@@ -1,13 +1,13 @@
 .. _swh-deposit-specs:
 
-Software Heritage Deposit Specifications
-========================================
+Blueprint Specifications
+=========================
 
 .. toctree::
    :maxdepth: 1
    :caption: Contents:
 
    blueprint.rst
    spec-loading.rst
    spec-sparse-deposit.rst
    spec-meta-deposit.rst