diff --git a/docs/specs/metadata_example.xml b/docs/specs/metadata_example.xml
index 59c5ed82..c681e559 100644
--- a/docs/specs/metadata_example.xml
+++ b/docs/specs/metadata_example.xml
@@ -1,38 +1,35 @@
<?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">
"{http://www.w3.org/2005/Atom}author": {
"{http://www.w3.org/2005/Atom}email": "hal@ccsd.cnrs.fr",
"{http://www.w3.org/2005/Atom}name": "HAL"
},
<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:manifest>
- <swh:object>
- <swh:path>./path/to/file.txt</swh:path>
- <swh:swhid>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</swh:swhid>
- </swh:object>
- </swh:manifest>
+ <swh:bindings>
+ <swh:binding source="path/to/file.txt" destination="aaaaaaaaaaa..."/>
+ </swh:bindings>
</swh:deposit>
</entry>
diff --git a/docs/specs/spec-meta-deposit.rst b/docs/specs/spec-meta-deposit.rst
index 9ba0c8ef..a4f700c8 100644
--- a/docs/specs/spec-meta-deposit.rst
+++ b/docs/specs/spec-meta-deposit.rst
@@ -1,104 +1,100 @@
-The meta-deposit
-================
+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
the metadata about an object or several objects in the archive.
The scope of the meta-deposit is different than the
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:type> origin </swh:type>
- <swh:target> https://github.com/user/repo </swh:target>
+ <swh:origin url='https://github.com/user/repo'/>
</swh:reference>
</swh:deposit>
</entry>
examples by target type
^^^^^^^^^^^^^^^^^^^^^^^
snapshot
*********
.. code:: xml
<swh:deposit>
<swh:reference>
- <swh:type> snapshot </swh:type>
- <swh:target> swh:1:snp:aaaaaaaaaaaaaa... </swh:target>
+ <swh:object id="swh:1:snp:aaaaaaaaaaaaaa..."/>
</swh:reference>
</swh:deposit>
revision
********
.. code:: xml
<swh:deposit>
<swh:reference>
- <swh:type> revision </swh:type>
- <swh:target> swh:1:rev:aaaaa............ </swh:target>
+ <swh:object id="swh:1:rev:aaaaa............"/>
</swh:reference>
</swh:deposit>
release
*******
.. code:: xml
<swh:deposit>
<swh:reference>
- <swh:type> release </swh:type>
- <swh:target> swh:1:rel:aaaaaaaaaaaaaa.... </swh:target>
+ <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.
diff --git a/docs/specs/spec-sparse-deposit.rst b/docs/specs/spec-sparse-deposit.rst
index 534957a8..6fd12f5c 100644
--- a/docs/specs/spec-sparse-deposit.rst
+++ b/docs/specs/spec-sparse-deposit.rst
@@ -1,109 +1,104 @@
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.
+----------------------+-------------------------------------+
| path | swh-id |
+======================+=====================================+
-| ./path/to/file.txt | swh:1:cnt:aaaaaaaaaaaaaaaaaaaaa... |
+| path/to/file.txt | swh:1:cnt:aaaaaaaaaaaaaaaaaaaaa... |
+----------------------+-------------------------------------+
-| ./path/to/dir/ | swh:1:dir: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:manifest>
- <swh:object>
- <swh:path>./path/to/file.txt</swh:path>
- <swh:swhid>swh:1:cnt:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</swh:swhid>
- </swh:object>
- <swh:object>
- <swh:path>./path/to/second_file.txt</swh:path>
- <swh:swhid>swh:1:cnt:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb</swh:swhid>
- </swh:object>
- <swh:object>
- <swh:path>./path/to/dir/</swh:path>
- <swh:swhid>swh:1:dir:ddddddddddddddddddddddddddddddddd</swh:swhid>
- </swh:object>
- </swh:manifest>
+ <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
Each one of the verifications 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
- 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.
diff --git a/docs/specs/swh.xsd b/docs/specs/swh.xsd
index 37ac2cca..4dbf0ac6 100644
--- a/docs/specs/swh.xsd
+++ b/docs/specs/swh.xsd
@@ -1,23 +1,41 @@
-<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
- <xs:element name="deposit">
- <xs:complexType>
- <xs:sequence>
- <xs:attribute type="xs:string" name="reference" minOccurs="0"/>
- <xs:element name="manifest" minOccurs="0">
- <xs:complexType>
- <xs:sequence>
- <xs:element name="object" minOccurs="0" maxOccurs="unbounded">
- <xs:complexType>
- <xs:sequence>
- <xs:attribute type="xs:string" name="path"/>
- <xs:attribute type="xs:string" name="swhid"/>
- </xs:sequence>
- </xs:complexType>
- </xs:element>
- </xs:sequence>
- </xs:complexType>
- </xs:element>
- </xs:sequence>
- </xs:complexType>
- </xs:element>
-</xs:schema>
+<?xml version="1.0" encoding="iso-8859-1"?>
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+ <xsd:element name="deposit">
+ <xsd:complexType>
+ <xsd:choice>
+
+ <xsd:element name="reference">
+ <xsd:complexType>
+ <xsd:choice>
+ <xsd:element name="object">
+ <xsd:complexType>
+ <xsd:attribute type="xsd:string" name="id"/>
+ </xsd:complexType>
+ </xsd:element>
+ <xsd:element name="origin">
+ <xsd:complexType>
+ <xsd:attribute type="xsd:string" name="url"/>
+ </xsd:complexType>
+ </xsd:element>
+ </xsd:choice>
+ </xsd:complexType>
+ </xsd:element>
+
+
+ <xsd:element name="bindings">
+ <xsd:complexType>
+ <xsd:sequence>
+ <xsd:element name="binding" minOccurs="0" maxOccurs="unbounded">
+ <xsd:complexType>
+ <xsd:attribute type="xsd:string" name="source"/>
+ <xsd:attribute type="xsd:string" name="destination"/>
+ </xsd:complexType>
+ </xsd:element>
+ </xsd:sequence>
+ </xsd:complexType>
+ </xsd:element>
+
+ </xsd:choice>
+ </xsd:complexType>
+ </xsd:element>
+</xsd:schema>