...

...

The body of the request is an XML

<nowiki>propfind</nowiki>

propfind element constraining the query.
It may contain either a single

<nowiki>propname</nowiki>

propname element (meaning just return
the names of all available properties),
a

<nowiki>prop</nowiki>

element prop element containing a sequence of

<nowiki>propname</nowiki>

{{propname}}s for which
to return values,
or an

<nowiki>allprop</nowiki>

allprop element meaning "return all available properties and values."

Finally, the `Depth` header
determines how deeply the query descends the hierarchy
of resources. A depth of

<nowiki>0</nowiki>

0 means just return properties on the resource
itself;

<nowiki>1</nowiki>

1 includes only the direct descendents (i.e. Items in a
Collection or Bitstreams in an Item). The special constant

<nowiki>INFINITY</nowiki>

INFINITY `(-1 in the SOAP call)` means return the chosen
properties on all descendents.

...

For example, the first URI visits all
of the collections and communities in the whole Site, while the
second only shows Collections under a given Community (avoiding
sub-Communities):

<nowiki>
  http://uni.edu/dspace/dav/?type=COMMUNITY&type=COLLECTION

  http://uni.edu/dspace/dav/dso_1721.1$3549?type=collection
</nowiki>

More on PROPFIND

See the propfind_xml description of the `propfind` XML element and
the WebDAV protocol specifcation
for complete details on the use of

<nowiki>propfind</nowiki>

and

<nowiki>multistatus</nowiki>

propfind and multistatus.

You can map the hierarchy of resources under a specific URI
by calling

<nowiki>propfind</nowiki>

propfind with
an empty list of properties, so it just returns the structure of resources
without any property data.

...

`PROPFIND`
returns the results in a

<nowiki>multistatus</nowiki>

multistatus element that contains
a

<nowiki>propstat</nowiki>

propstat element for each property found.
See the WebDAV protocol specifcation
for
more details.

...

The body of the request
is an XML

<nowiki>propertyupdate</nowiki>

propertyupdate element describing the properties to
be changed or removed. It contains a series of

<nowiki>set</nowiki>

and

<nowiki>remove</nowiki>

set and remove elements, each has
a

<nowiki>prop</nowiki>

prop element child describing the property to be set or deleted.

`PROPPATCH` reurns a

<nowiki>multistatus</nowiki>

multistatus element similar to the one returnd by

<nowiki>propfind</nowiki>

propfind, with a separate status for each property that was changed.

...

See the propfind_xml description of the `proppatch` XML element andhttp://www.webdav.org/specs/rfc2518.html the WebDAV protocol specifcation]
for complete details on the use of

<nowiki>propfind</nowiki>

and

<nowiki>multistatus</nowiki>

propfind and multistatus.

COPY

The `COPY` method
creates what appears to be a copy of a resource at a new location.
It actually just
establishes a link, or reference, to the resource at the destination
location, but
we use the `COPY` method because
of all the core WebDAV methods,
it comes
closest to having the right semantics.

...

The general format of a GET URI is:

GET URI for Item::

<nowiki>/</nowiki>

<nowiki>/</nowiki>

<nowiki>?package=</nowiki>

  *{{/}}\* _prefix_ \*{{/}}\* _resource_path_ \*{{?package=}}\* _package-format_ *_&other-packager-parameters

{_}*
GET URI for Bitstream::

<nowiki>/</nowiki>

<nowiki>/</nowiki>

  *{{/}}\* _prefix_ \*{{/}}\* _resource_path_ _\[ .optional-extension \]_

...

When the resource is a bitstream, the package query arg is omitted, since the
bitstream is always sent unpackaged. You can always add an extension to
the bitstream URI, since this helps some HTTP clients handle the content
correctly.

<nowiki>GET</nowiki>

GET is not implemented for Communities and Collections. `PROPFIND` can
fetch all of the significant information about those types of objects, namely
their administrative metadata and their member objects.

Some examples of GET requests:

<nowiki>
    GET /dspace/dav/dso_1721.1$5543?package=METS&dmd=MODS

    GET /dspace/dav/dso_1721.1$5543/bitstream_13

    GET /dspace/dav/dso_1721.1$5543/bitstream_13.pdf
</nowiki>

GET Headers

The GET request also responds to HTTP request headers to modify the
request:

...

If the client does not want to transfer a large object (e.g. multi-gigabyte
video clip) in one transaction, it can use the

<nowiki>Range</nowiki>

Range header to
break up the transfer into multiple requests. If one of those fails,
it is faster (and perhaps safer) to retry it than to redo a large transfer.

...

The HTTP response from such a `PUT` includes a

<nowiki>Location</nowiki>

Location header with
the URI of the new Item, so the client can find out the URI (and thus
the persistent identifier, if available) of the Item it created.

...

For example, to add a new item to the Collection at handle

...

1721.1/

...

3549, we observe the following request and response:

<nowiki>
Request:    PUT /dspace/dav/dso_1721.1$3549?package=OCW-IMSCP
             ....package contents in body...

Response:   HTTP/1.1 201 OK
            Location: http://uni.edu/dspace/dav/dso_1721.1$F5549
             ....other headers....
</nowiki>

PUT Semantics: Adding an Item to Multiple Collections

...

• Content-Length:: The number of bytes in the content block following the request and entity headers.
• Content-MD5:: An MD5 checksum of the content. This is optional but encouraged. The checksum applies only to the bytes sent, in the case of a subset defined by a

  Code Block
  <nowiki>Content-Range</nowiki>

  Content-Range header.
• Content-Range:: This request only includes part of the entity. In this network interface, ranges MUST be consecutive and MUST be sent in their natural order.

...

The client makes inquiries about properties with the `PROPFIND` method,
and the query itself is defined by the `propfind` XML element supplied
in the request body.
For
example, this query gets the `displayname` WebDAV property,
`dspace:type` (DSpace object type),
and `getlastmodified` (the WebDAV last-modified time):

<nowiki>
<propfind xmlns="DAV:">
  <prop xmlns:dspace="http://www.dspace.org/xmlns/dspace">
    <displayname/>
    <getlastmodified/>
    <dspace:type/>
  </prop>
</propfind>
</nowiki>

The result of a `PROPFIND` is a

<nowiki>multistatus</nowiki>

{{multistatus}}element, which contains the status (success/failure) of the query of
each property on each resource, and the property values in `propstat` elements.
This example returns successfully for the

...

...

"displayname"

...

and `dspace:type` properties, and fails
to access the

...

"getlastmodified"

...

property:

<nowiki>
<multistatus xmlns="DAV:">
  <response>
    <href>/dspace/dav/dso_1721.1$5543</href>
    <propstat xmlns:dspace="http://www.dspace.org/xmlns/dspace">
      <prop>
        <displayname>Zen and the Art of Java Maintenance</displayname>
        <dspace:type>
          <dspace:item/>
        </dspace:type>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
    <propstat>
      <prop>
        <getlastmodified/>
      </prop>
      <status>HTTP/1.1 403 Forbidden<status>
      <responsedescription>
      You do not have the right to read getlastmodified.
      </responsedescription>
    </propstat>
  </response>
</multistatus>
</nowiki>

The client modifies and deletes properties with the `PROPPATCH` method,
and the instructions on what to do are encoded in a
`propertyupdate` element
in the request body.

...

Here is an example that changes (or adds) the `displayname` property and
removes `dspace:license`:

<nowiki>
<propertyupdate  xmlns="DAV:" xmlns:dspace="http://www.dspace.org/xmlns/dspace">
  <set>
    <prop>
      <displayname>Zen and the Art of Java Maintenance</displayname>
    </prop>
  </set>
  <remove>
    <prop>
      <dspace:license>
    </prop>
  </remove>
</propertyupdate>
</nowiki>

DSpace-specific Properties

...

DSpace resources also support the required Web D A V properties, and some
optional ones. They are prefixed with

<nowiki>DAV:</nowiki>

DAV: to represent the namespace
URI, which is also `DAV:`.

ALL DSpace Resources::

• Code Block
  <nowiki>dspace:type</nowiki>

  dspace:type – DSpace Object type, the value is an element whose name is the type in lowercase, e.g. one of Code Block<nowiki><dspace<dspace:bitstream>, <dspace:item>, <dspace:collection>, <dspace:community>, <dspace:site></nowiki>site>, etc.

• Code Block
  <nowiki>DAV:resourcetype</nowiki>

  DAV:resourcetype – WebDAV resource type, value is either Code Block<nowiki><DAV<DAV:collection/></nowiki>> for a collection or empty for an "atom".

• Code Block
  <nowiki>DAV:displayname</nowiki>

  DAV:displayname – Label for a human-readable display of this resource, typically title or filename.
• Code Block<nowiki>DAVDAV:current-user-privilege-set</nowiki>set – The permissions the current user has to access this resource, in the format specified by the WebDAV Access Control Protocol RFC3744. Note that we do not (yet) implement any more of RFC3744.

Site (root of URI hierarchy)::

• Code Block<nowiki>dspacedspace:news_top</nowiki>top – News (string) to be displayed in the top area of the DSpace home page. Code Block<nowiki>dspace
• dspace:news_side</nowiki>side – News (string) to be displayed in the sidebar of the DSpace home page. Code Block<nowiki>dspace
• dspace:default_license</nowiki>license – Site-wide default license text applying to new items. Read-only.

Community objects::

• Code Block
  <nowiki>dspace:logo</nowiki>

  dspace:logo – actual image content of the logo image, in a `<bitstream>` tag bitstream_xml (see below). Code Block
• <nowiki>dspacedspace:short_description</nowiki>description – short description. Code Block<nowiki>dspace
• dspace:introductory_text</nowiki>text – short introductory text.
• Code Block<nowiki>dspacedspace:side_bar_text</nowiki>text – sidebar text (news) to show on community page. Code Block<nowiki>dspace
• dspace:copyright_text</nowiki>text – copyright statement to show on community page.

• Code Block
  <nowiki>dspace:handle</nowiki>

  dspace:handle – the persistent identifier of this resource in URN format, e.g. `hdl:123.45/6789`.

Collection objects::

• Code Block
  <nowiki>dspace:logo</nowiki>

  dspace:logo – actual image content of the logo image, in a `<bitstream>` tag bitstream_xml (see below). Code Block
• <nowiki>dspacedspace:short_description</nowiki>description – short description. Code Block<nowiki>dspace
• dspace:introductory_text</nowiki>text – short introductory text.
• Code Block<nowiki>dspacedspace:side_bar_text</nowiki>text – sidebar text (news) to show on collection page. Code Block<nowiki>dspace
• dspace:copyright_text</nowiki>text – copyright statement to show on collection page.
• Code Block<nowiki>dspacedspace:default_license</nowiki>license – default license text applying to new items. Code Block<nowiki>dspace
• dspace:provenance_description</nowiki>description – the `"provenance_description"` metadata for collection, whatever that is.

• Code Block
  <nowiki>dspace:handle</nowiki>

  dspace:handle – the persistent identifier of this resource in URN format, e.g. `hdl:123.45/6789`.

Item objects::

• Code Block
  <nowiki>dspace:submitter</nowiki>

  dspace:submitter – ePerson resource of original submitter of this item. Code Block<nowiki>dspace
• dspace:owning_collection</nowiki>collection – persistent identifier (handle) of Collection that owns this item.

• Code Block
  <nowiki>dspace:license</nowiki>

  dspace:license – contents of license bitstream for this item, in a `<bitstream>` tag bitstream_xml (see below). Code Block
• <nowiki>dspacedspace:cc_license_text</nowiki>text – text of Creative Commons license bitstream for this item, in a `<bitstream>` tag bitstream_xml (see below). Code Block<nowiki>dspace
• dspace:cc_license_rdf</nowiki>rdf – RDF of Creative Commons license bitstream for this item, in a `<bitstream>` tag bitstream_xml (see below).
• Code Block<nowiki>dspacedspace:cc_license_url</nowiki>url – URL of Creative Commons license for this item.

• Code Block
  <nowiki>DAV:getlastmodified</nowiki>

  DAV:getlastmodified – This DAV property is assigned the DSpace last-modified date.

• Code Block
  <nowiki>dspace:handle</nowiki>

  dspace:handle – the persistent identifier of this resource in URN format, e.g. `hdl:123.45/6789`.

• Code Block
  <nowiki>dspace:withdrawn</nowiki>

  dspace:withdrawn – `true` or `false`, indicating whether the Item has been withdrawn. This is the only property most users will have permission to read on a withdrawn Item.

Bitstream objects::

• Code Block
  <nowiki>DAV:getcontentlength</nowiki>

  DAV:getcontentlength – value returned by bitstream's Code Block<nowiki>[[get Size]]</nowiki>.

• Code Block
  <nowiki>DAV:getcontenttype</nowiki>

  DAV:getcontenttype – mimetype from bistream's format.
• NOTE: the DSpace object model _has no notion of `getcontentlength` for Bitstreams, so we cannot offer it._

• Code Block
  <nowiki>dspace:source</nowiki>

  dspace:source – bitstream's

  Code Block
  <nowiki>source</nowiki>

  source attribute.

  Code Block
  <nowiki>dspace:description</nowiki>

• dspace:description – bitstream's

  Code Block
  <nowiki>description</nowiki>

  description attribute.

• Code Block
  <nowiki>dspace:format</nowiki>

  dspace:format – bitstream's Code Block<nowiki>[[get Format]]().getID()</nowiki>. Code Block<nowiki>dspace
• dspace:format_description</nowiki>description – bitstream's Code Block<nowiki>[[get User Format Description]]</nowiki>.

  Code Block
  <nowiki>dspace:checksum</nowiki>

• dspace:checksum – bitstream's Code Block<nowiki>[[get Checksum]]()</nowiki>.
• Code Block<nowiki>dspacedspace:checksum_algorithm</nowiki>algorithm – bitstream's Code Block<nowiki>[[get Checksum Algorithm]]()</nowiki>. Code Block<nowiki>dspace
• dspace:sequence_id</nowiki>id – returned by bitstream's Code Block<nowiki>[[get Sequence I D]]</nowiki>.

• Code Block
  <nowiki>dspace:bundle</nowiki>

  dspace:bundle – name of bundle in which bitstream was created.

• Code Block
  <nowiki>dspace:handle</nowiki>

  dspace:handle – the persistent identifier of this resource in URN format, e.g. `hdl:123.45/6789` (but usually not available for bitstreams (yet?))

In-progress Item::

• Code Block
  <nowiki>dspace:submitter</nowiki>

  dspace:submitter – EPerson resource of original submitter of this item.

• Code Block
  <nowiki>dspace:collection</nowiki>

  dspace:collection – persistent identifier (handle) of Collection to which this item is being submitted.
• Code Block<nowiki>dspacedspace:has_multiple_files</nowiki>files – value of `has Multiple Files()` Code Block<nowiki>dspace
• dspace:has_multiple_titles</nowiki>titles – value of `has Multiple Titles()`
• Code Block<nowiki>dspacedspace:is_published_before</nowiki>before – value returned by `is Published Before()`
• Every in-progress item also has one child resource which is a DSpace Item.

...

• all properties of the In-progress Item, and:
• Code Block<nowiki>dspacedspace:stage_reached</nowiki>reached – Symbolic name of the last stage reached in the submission process.
  *

  Code Block
  <nowiki>dspace:state</nowiki>

  
  *dspace:state --Write-Only: Change this to the keyword `start` or `start_without_notify` to enter a workspace item into its collection's workflow.

...

• all properties of the In-progress Item, and:

• Code Block
  <nowiki>dspace:owner</nowiki>

  dspace:owner – EPerson resource of owner of this workflow item.
  *

  Code Block
  <nowiki>dspace:state</nowiki>

  dspace:state – When read, returns the symbolic name of the current workflow step, e.g. `STEP1_POOL`. You can also*set* this property to one of the following keywords to manipulate its place in the workflow: (See API doc for `org.dspace.workflow.Workflow Manager` for details)
• `abort` – Aborts workflow, returning item to its submitter's workspace.
• `reject` – Reject an item at `STEP1`, send mail to submitter, otherwise the same as `abort`.
• `advance` – Move an item to the pool for the next step, or archive it if it was on the last step. You must have previously claimed the workflow item.
• `claim` – Take responsibility for a workflow item that was in the pool of unclaimed items.
• `unclaim` – Return an item you have claimed to the pool.

...

• `dspace:email` – email address.
• `dspace:first_name` – first, or given name.
• `dspace:last_name` – last, or family name.
• `dspace:require_certificate` – if true, this eperson can only login with an X.509 client certificate.
• `dspace:self_registered` – eperson record created by selfsame user.
• `dspace:can_login` – if true, user is allowed to login.

• Code Block
  <nowiki>dspace:handle</nowiki>

  dspace:handle – the persistent identifier of this resource in URN format, e.g. `hdl:123.45/6789` (but not available for epersons yet?))

...

Anchor(bitstream_xml)The `logo` attribute's value is a bitstream of an image. It is represented
by the `dspace:bitstream` XML element, which gives the choice of encoding
the bitstream as either a link (to an external resource) or inline base64-encoded data.
The inline encoding should only be used for small (a few Kb) images.
This example shows both alternatives:

<nowiki>
   <!-- link to external resource -->
   <dspace:bitstream>
     <dspace:link href="http://dspace.myuniv.edu/dspace/dav/retrieve_54321" />
   </dspace:bitstream>

   <!-- inline encoding -->
   <dspace:bitstream>
     <dspace:content contenttype="image/gif" contentlength="299" contentencoding="base64">
       ...text of base64-encoded data...
     </dspace:content>
   </dspace:bitstream>
</nowiki>

SOAP API Calls

This Java class outline shows the LNI's SOAP RPC interface, which
is accessed through the `org.dspace.app.dav.client.L N I Soap Servlet` class.
The utility class `org.dspace.app.dav.client.L N I Client Utils` also
has some methods of use to client writers.

...

'''NOTE: Every feature of the LNI is available
through WebDAV (HTTP); this API is provided for callers
who prefer to use SOAP RPCs where possible.'''

<nowiki>
public class org.dspace.app.dav.client.[[L N I Soap Servlet]] {

  /**
  *** Returns Resource URI for the DSpace Object whose persistent
  *** identifier (i.e. Handle) is  "handle".  Optionally add Persistent ID
  *** (sequence ID) of a bitstream under the Item, if a URI to a bitstream
  *** is desired, otherwise bitstreamPID should be null.
  *** This does the same thing as the /lookup URI.
  ***/
  public String lookup(String handle, String bitstreamPID)
    throws java.rmi.[[Remote Exception]], org.dspace.app.dav.client.[[L N I Remote Exception]]

  /**
  *** Same as PROPFIND WebDAV method.  "uri" may be relative to DSpace LNI
  *** prefix, or absolute; "propfind" is the propfind element, and depth is
  *** the content of the "Depth:" header.  Depth should be 0, 1, or the
  *** constant org.dspace.app.dav.client.[[L N I Client Utils]].INFINITY (-1).
  *** Types is a comma-separated list of DSpace item types to which to
  *** restrict the query (see "type" option of PROPFIND method). May be null.
  *** Returns the multistatus document from the method's response.
  ***/
  public String propfind(String uri, Document propfind, int depth, String types)
    throws java.rmi.[[Remote Exception]], org.dspace.app.dav.client.[[L N I Remote Exception]]

  /**
  *** Same as PROPPATCH WebDAV method.  "uri" may be relative to DSpace
  *** LNI prefix, or absolute; "propertyupdate" is the propertyupdate
  *** element.  Returns the multistatus document from the method's response.
  ***/
  public String proppatch(String uri, String propertyupdate)
    throws java.rmi.[[Remote Exception]], org.dspace.app.dav.client.[[L N I Remote Exception]]

  /**
  *** Executes COPY method; "uri" and "destination_uri" may be relative
  *** to DSpace LNI prefix, or absolute.
  *** The depth and [[keep Properties]] parameters correspond to
  *** parameters on the actual COPY WebDAV method, but DSpace ignores them
  *** at this time.
  *** The overwrite option will allow the copy to overwrite an existing
  *** resource if necessary.
  ***
  *** Returns the HTTP status code.
  ***/
  public int copy(String uri, String destination_uri, int depth,
                  boolean overwrite, boolean [[keep Properties]])
    throws java.rmi.[[Remote Exception]], org.dspace.app.dav.client.[[L N I Remote Exception]]
  }

  public class org.dspace.app.dav.client.[[L N I Client Utils]] {

  /** Depth of infinity in SOAP propfind() */
  public final static int INFINITY = -1;

  /**
  *** Make up a URL to access a WebDAV resource, given the SOAP "endpoint" URL
  *** and a relative URI such as is returned by lookup().  Clients should
  *** use this to obtain URLs to make HTTP GET and PUT requests.
  *** Packager may be null for a resource such as a Bitstream that does
  *** not require a packager.
  ***/
  public static URL makeDAVURL(String endpoint, String davURI, String packager);
    throws MalformedURLException

  /** alternate version that does not require packager. */
  public static URL makeDAVURL(String endpoint, String davURI);
    throws MalformedURLException

  /**
  *** Translates a WebDAV URL, such as would be returned by the PUT
  *** method, into a resource URI relative to the DAV root which can
  *** be passed to the SOAP methods.  Inverse of makeDAVURL.
  ***/
  public static String makeLNIURI(String endpoint, String davURL)
    throws MalformedURLException
  }
</nowiki>

Security Considerations

The LNI's approach to security has two layers: First, authenticationand authorization, to let DSpace administrators control access
to the resources in the archive. Second is confidentiality, which
protects the contents of LNI transactions and the archive content itself
from being copied as they are transmitted over the Internet.

...

Here is an example of how a client would create a session and issue
a `propfind` call with the LNI. It assumes the SOAP interface is built
upon Apache's Axis SOAP implementation.

<nowiki>
  // DSpace credentials are either user/password in the URL, or X.509
  // client cert supplied with https: connection.
  String endpoint = "http://user:password@dspace.uni.edu/dspace/lni/DSpaceLNI";

  // get Axis locator
  [[Lni Soap Servlet Service Locator]] locator = new [[Lni Soap Servlet Service Locator]]();

  // create client endpoint
  [[Lni Soap Servlet]] lni = locator.getDSpaceLNI(new java.net.URL(endpoint));

  // get resource URI for known handle:
  String handle = "1234.56/789";
  String [[resource Uri]] = lni.lookup(handle, null);

  // get its properties..
  String result = lni.propfind([[resource Uri]],
        "<propfind xmlns=\"DAV:\"><allprop /></propfind>", 1);

  // ..now parse and display the XML in "result"..
</nowiki>

B. Submit a new Item to multiple collections

Start with the item in an acceptable package format, for example, an
IMSCP content package in a Zip file. The goal is to install it in
two collections (handles

<nowiki>123456789/11</nowiki>

and

<nowiki>123456789/22</nowiki>

123456789/11 and 123456789/22).
Here are the HTTP WebDAV requests you would make:

1. Do a `GET` on `/dspace/dav/lookup/handle/123456789/11` to get the LNI resource URI for the first collection, which will be `/dspace/dav/dso_123456789$11`.
2. Submit the item with a

   Code Block
   <nowiki>PUT</nowiki>

   PUT request to Code Block<nowiki>/dspace/dav/dso_123456789$11?format=IMSCP</nowiki>IMSCP
3. The response to the

   Code Block
   <nowiki>PUT</nowiki>

   PUT includes a `Location:` header giving the URI of the item it created, e.g. `Location: /dspace/dav/workflow/wfi_db_23`
4. To add it to the second collection, start with a `GET` on `/dspace/dav/lookup/handle/123456789/22` to get the LNI resource URI for the second collection, which will be `/dspace/dav/dso_123456789$22`.
5. Issue the request Code Block<nowiki>COPY COPY /dspace/dav/workflow/23</nowiki>23 with the header, `Destination: /dspace/dav/dso_123456789$22` to add the workflow item to the second collection. When the Item gets through workflow and is archived, it will appear in both collections.

NOTE: If there is no workflow and the item gets archived immediately,
you would get back a regular Item URI in the

<nowiki>Location:</nowiki>

Location: header of
the response to the

<nowiki>PUT</nowiki>

PUT and would copy that into the new collection.

...

This example gets a dissemination of the item at handle

<nowiki>123456789/33</nowiki>

123456789/33 in the default format, which is (probably)
a DSpace METS-based
package very much like the internal AIP format, used e.g. for exchange
between DSpace instances.

If the item is readable to the

<nowiki>Anonymous</nowiki>

Anonymous group, we do not need to
authenticate.

1. Do a `GET` on `/dspace/dav/lookup/handle/123456789/33` to get the LNI resource URI for that handle.
2. The client sends a

   Code Block
   <nowiki>GET</nowiki>

   GET request to the URI Code Block<nowiki>/dspace/dav/dso_123456789$33?package=METS</nowiki>METS
3. The response from the server is status 200 (success) followed by entity headers Code Block<nowiki>ContentContent-Type: application/zip</nowiki>zip, any other relevant headers, and finally the Zip file data.

...

Note that getting the list of all communities and collections on
the DSpace Site may be slow if there are very many of them, so this should be
narrowed down to a single Community (or repeated for several communities
of interest) if it needs to be faster.

1. Call

   Code Block
   <nowiki>propfind</nowiki>

   propfind on the URI `"/dspace/dav/?type=COMMUNITY&type=COLLECTION"`, depth=`INFINITY` and the

   Code Block
   <nowiki>propfind</nowiki>

   propfind request document shown below, which lists the relevant authorization properties.
2. Examine the

   Code Block
   <nowiki>multistatus</nowiki>

   multistatus document returned by `propfind`, looking for resources whose Code Block<nowiki>DAVDAV:current_user_privilege_set</nowiki>set properties include the element `DAV:bind` (or `DAV:all`). These are the Collections into which you can submit.

Here is the document to send with the

<nowiki>propfind</nowiki>

propfind request:

<nowiki>
   <propfind xmlns="DAV:">
     <prop xmlns:dspace="http://www.dspace.org/xmlns/dspace">
       <DAV:current_user_privilege_set />
     </prop>
   </propfind>
</nowiki>

Extending the Network Interface

...

• The Registry URI is _/prefix_ Code Block<nowiki>/format/</nowiki>
• Each Bitstream Format's URI is _/prefix__ Code Block<nowiki>/format/</nowiki>_short-description
• `GET` is not implemented on any of these resources.
• `PUT` of a new Bitstream Format URI creates it. The request body must be empty.
• Bitstream Format resources have the following properties. They are all settable unless marked read-only.
  • `DAV:displayname` – same as description
  • `DAV:resourcetype` – empty. (`/format/` is a collection).
  • `dspace:type` – `<bitstream-format/>`
• *`description` – Full description of the bitstream format.
• *`extensions` – Comma-separated list of filename extensions associated with this format.
• *`ID` – READ-ONLY; internal database ID of this format.
• *`MIMEType` – Internet format type, aka MIME type, associated with this format. May not be unique amongst formats.
• *`support Level` – Support level, one of `UNKNOWN`, `KNOWN`, `SUPPORTED`.
• *`is Internal` – Is this format useed to store internal system information, rather than content? One of `TRUE`, `FALSE`.

...

• PUT Method:: Implement `PUT` on a Bitstream resource to replace its contents, and on an Item to replace it with the contents of a new package. This is waiting for policy decisions and possibly a versioning mechanism.
• DELETE Method:: DSpace objects are usually never deleted, although the object API supports it. Perhaps `DELETE` is worth implementing only for some types of resources.
• MKCOL Method:: Create a new collection, i.e. DSpace Collection or Community. Have it create an empty/blank object and then set properties with

  Code Block
  <nowiki>proppatch</nowiki>

  proppatch.
• MOVE Method:: Possibly useful for rearranging the namespace, i.e. moving children of Collections and Communities around.
• LOCK Method:: Not implemented, and not strictly required by WebDAV. Recommended that this be left out until DSpace has versioning.
• Versioning:: Not implemented, and not strictly required by WebDAV. Recommended that this be left out until DSpace has versioning.

...

Wreilly 15:42, 12 June 2009 (EDT)</html>