SWORD APP Profile 1.0

From DigiRepWiki

SWORD Home | SWORD Wiki | SWORD Project Background


This profile has been replaced by the most recent version: http://purl.org/net/sword/


Contents

SWORD Profile of the Atom Publishing Protocol

Version 1.0, created 12th October 2007.

Editors:

  • Julie Allinson (UKOLN/Univerity of York)
  • Martin Morrey (Intrallect Ltd.)
  • Neil Taylor (University of Aberystwyth)
  • Stuart Lewis (University of Aberystwyth)
  • Glen Robson (National Library of Wales)
  • Richard Jones (Imperial College London)
  • Les Carr (University of Southampton)
  • Sebastien Francois (University of Southampton)
  • Jim Downing (University of Cambridge)
  • David F. Flanders (The Bloomsbury Colleges)

Introduction

This document is a profile of the Atom Publishing Protocol (APP [ATOMPUB]). APP [ATOMPUB] is an application-level protocol for publishing and editing Web resources. The APP is based on HTTP transfer of Atom-formatted representations. This Profile specifies a subset of elements from the APP for use in depositing content into information systems, such as repositories. The Profile also specifies a number of element extensions to APP, defined to adhere to the extensions mechanism outlined in APP. This profile also makes use of the Atom Syndication Format (ATOM - [RFC4387]) as used in APP, with extensions.

This profile has been produced to support the work of the JISC-funded SWORD project. It defines a specific implementation of the APP [RFC4387], along with a number of extensions which support the requirements identified by the SWORD project. The SWORD profile is concerned only with the deposit (POST) of data files or packages and defines a mechanism for POST that adheres closely to section 9.6 of APP [RFC4387]. Implementers wishing to support additional elements of APP, such as update (PUT), DELETE, categories or POSTing ATOM - [RFC4387] documents are free to do so. This is considered an additional to SWORD and such implementations can still achieve be SWORD-compliant. See the section on Compliance.

Document conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 (see APP [ATOMPUB]).

SWORD namespace

http://purl.org/net/sword/

SWORD Profile of APP elements

The following section identifies the elements of APP [ATOMPUB] which are implemented by SWORD and those which are not. It also provides additional requirements and recommendations, and identifies SWORD extensions to APP, using elements from other namespaces and elements from the sword namespace.

The section is organised according to the sections of the APP [ATOMPUB] document.

5. Protocol Operations

5.1 Retrieving a Service Document

SWORD supports the use of HTTP GET requests.

GET to Service Document

In addition, SWORD defines an additional HTTP header 'X-On-Behalf-Of' used to specify the username of a target user on whose behalf a deposit is being made.

GET to Service Document
X-On-Behalf-Of: on-behalf-of-user

This facilitates the SWORD requirement to support mediated deposits. See also the notes about Authentication below (relating to APP section 14). When supplying an X-On-Behalf-Of value, the returned Service Document SHOULD identify only those collections to which the target user is able to deposit. If the target repository does not support mediated deposit, the returned Service Document SHOULD contain a <sword:mediation> extension element with a value of false.

5.2 Listing Collections - NOT USED

5.3 Creating a Resource

SWORD supports the use of HTTP POST.

POST to URI of Collection
201 Created
Location: Member Entry URI

See further refinements to the SWORD use of HTTP POST in Section 9.

5.4 Editing a Resource - NOT USED

5.5 use of HTTP Response Codes

SWORD defines the use of the following HTTP response codes. Implementers MUST support the following codes. It is RECOMMENDED that human-readable explanations are supplied along with HTTP response codes.

  • 201 Created - indicates that a deposit was successful and has been added into some part of the repository workflow.
  • 202 Accepted - indicates that the deposit was successful and has been accepted pending checking by the repository.
  • 400 Bad Request - indicates that there is some problem with the structure of the request.
  • 401 Unauthorized - indicates that the is not authorised to deposit in the specified collection.
  • 403 Forbidden - indicates that there was a problem making the deposit, it may be that the depositor is not authorised to deposit on behalf of the target owner, or the target owner does not have permission to deposit into the specified collection.
  • 412 Precondition failed - indicates a checksum mismatch.
    • level 0 implementations MAY, and level 1 implementations MUST return a 412 if the MD5 checksum does not match.
  • 415 Unsupported Media Type - indicates that the format supplied in not accepted by the repository.
    • level 0 implementations MAY, and level 1 implementations MUST return a 415 if the content-type supplied is not supported by the server.
  • 500 Internal Server Error -
    • level 1 implementations SHOULD return a 500 for any other error.
  • 501 Not implemented - indicates that the supplied URI has been allocated to the item, but cannot yet be dereferenced

In addition, SWORD has defined the X-Error-Code header to be used in addition to the above error codes to supply additional error detail. SEE SWORD Extensions to the APP.

7. Category Documents - NOT USED

8. Service Documents

In line with APP, a service document (<app:service>) is identified with the "application/atomsvc+xml" media type.

8.1 Workspaces

The SWORD profile supports the APP [ATOMPUB] definition of a Workspace.

For this profile, a Workspace is defined as an arbitrary aggregation of collections of resources.

For the SWORD profile one or more <app:collection> elements SHOULD be present. The absence of any <app:collection> elements implies that the authenticated user does not have permission to deposit.

For level 1 compliance the <app:accept> element MUST be used to specify accepted media-ranges. It is anticipated that these ranges will include media ranges relating to accepted packaging formats, e.g. application/zip, application/xml. SWORD also specifies an extension point for supplying a namespace for a specific deposit format. SEE SWORD Extensions to the APP. Implementers MAY support additional formats.

Implementers SHOULD support application/zip used for simple cases of deposit of a data file and metadata. It is anticipated that the following packaging formats MAY be supported:

  • IMS content packaging
  • METS
  • DIDL

The SWORD profile supports the element definitions identified at 8.3.1, 8.3.2, 8.3.2.1, 8.3.3, 8.3.3.2, 8.3.3.3, 8.3.4.

SWORD defines the following extensions to the <app:collection> element:

<sword:collectionPolicy> - text/URI
<dcterms:abstract> - text/URI
<sword:mediation> - true|false
<sword:treatment> - text
<sword:formatNamespace> - URI

and the following extensions to the <app:service> element:

<sword:verbose> - true|false
<sword:noOp> - true|false
<sword:level> - 0|1

Consult the SWORD extensions to the APP for further definitions and usage guidelines.

8.3.5 - NOT USED

9. Creating and Editing Resources

9.1 Member URIs

SWORD supports Member URIs.

9.2 Creating resources with POST

SWORD supports the APP [ATOMPUB] use of 'POST to URI of collection' as outlined in section 9.6 of the APP [ATOMPUB]. Additionally SWORD uses HTTP headers to supply additional parameters with the POST. The following headers are defined:

  Content-MD5: md5-checksum
  Content-Disposition: filename=deposit-filename
  X-On-Behalf-Of: on-behalf-of-user
  X-Verbose: true|false
  X-No-Op: true|false
  X-Format-Namespace: format-namespace-uri

Consult the SWORD extensions to the APP for further definitions and usage guidelines.

9.3 Updating Resources with PUT - NOT USED

9.4 Deleting Resources with DELETE - NOT USED

9.5 Caching and entity tags - NOT USED

9.6 Media Resources and Media Link Entries

SWORD is primarily concerned with depositing binary files/packages of content rather than ATOM documents - implementers should pay particular attention to section 9.6 below and to section 9.6 in the APP [ATOMPUB].

SWORD supports the APP [ATOMPUB] mechanism for posting media types other than appliation/atom+xml to a Collection.

SWORD makes the following additional recommendations:

For level 1 compliance the server MUST signal the media types it will accept using the <app:accept> element in the Service Document, as specified in Section 8.3.4.

The Location: element of the HTTP header response MUST contain a URI for the Media Link Entry. The Media Link Entry is the Atom Entry Document created for the deposit and returned with the response. This is identified by the Media Link Entry URI which MUST be a unique identifier.

The <atom:id> element MUST contain a unique identifier for the deposit.

The deposit client MAY suggest a unique identifier using the Slug header. For level 1 compliance, if a depositor includes a Slug header this value MUST be stored within the metadata associated with that deposit if it is not used as the <atom:id>.

According to APP, The Media Link Entry MUST contain an <atom:content> element with a src attribute containing a URI for the deposited Media Resource (the deposited package). For SWORD implementations, this URI SHOULD identify the original deposited package. It MAY dereference to the package.

According to APP, an <atom:link> element SHOULD be supplied with a rel="edit-media" attribute and a href attribute containing a URI for the Media Resource. It is OPTIONAL that this URI be the same as that supplied as the src attribute of the <atom:content> element. SWORD makes no further recommendations about what this link element should resolve to; examples might include a representation which supplies metadata from the package and access to unpacked binary files. Alternatively, a repository might supply multiple <atom:link> elements to identify each unpacked resource. This is an implementation decision.

According to APP, an <atom:link> element MAY be supplied with a rel="edit" attribute and a href attribute containing a URI for the Media Link Entry metadata. SWORD makes no further recommendations about what this link element should resolve to; examples might include a jump-off page, users private metadata or workflow management page. This link MAY allow authorized users to make further edits to the atom, or other, metadata.

Wherever practical, URIs SHOULD dereference to a logical location, SHOULD be unique and SHOULD persist.

Where URIs do not dereference a 501 Not Implemented HTTP error code SHOULD be returned, with a human-readable explanation.

9.7 The Slug: Header

The SWORD Profile does not require the use of The Slug header at level 0. For level 1 compliance the Slug header MAY be used to supply a deposit identifier, for use as the <atom:id> value. Servers MAY choose to ignore the header or alter its value. For level 1 compliance, servers SHOULD retain the value of the Slug header, if supplied.

The Atom Entry Document

On successfully accepting a POST (deposit), implementers MUST return an Atom Entry Document with the HTTP response. The Atom Entry Document MUST contain information about the 'deposit'; this is not the same as the metadata describing the file(s) within the package which SHOULD be supplied within the package itself. Implementers are free to extend their use of the <atom:content> element to carry additional metadata but this is beyond the scope of this profile.

The following elements are mandatory in the Atom Entry Document (as specified by ATOM - [RFC4387]) and thus are also mandatory for SWORD level 0. The <atom:author> element should be used for a username or similar for the depositor. The <atom:content> and <atom:id> elements should be used as outlined above.

<atom:id>
<atom:author>
<atom:title>
<atom:updated>
<atom:content>

For full SWORD level 1 compliance the Atom Entry Document MAY contain the following extensions; it MUST contain treatment, source/generator and formatNamespace:

<atom:contributor>
<atom:source>
       <atom:generator uri=""> - uri and name of the source repository/client; optional version
<sword:treatment> - text
<sword:verboseDescription> - text description
<sword:noOp> - true/false (true = no action has been taken; 
  false = deposit has been made as requested)
<sword:formatNamespace> - uri for the format namespace

Consult the SWORD extensions to the APP for further definitions and usage guidelines.

10. Listing Collections - Not Used

  • APP [ATOMPUB] states that "Collection Resources MUST provide representations in the form of Atom Feed couments whose Entries contain the IRIs of Members in the Collection".
  • The SWORD profile does not require Collection lists, but implementers MAY wish to support this feature in order to be APP [ATOMPUB] compliant.

10.1 Collection partial lists - NOT USED

  • see notes above - implementers MAY wish to use Collection partial lists.

10.2 The "app:edited" Element - NOT USED

11. Atom Format

The SWORD Profile uses the "edit" and "edit-media" link relations. The SWORD profile does not currently support updates to deposited items, therefore a URI with an edit or edit-media link relation points to a Member Entry which MAY be editable, but is not required to be.

12. The Atom Format Type Parameter

The SWORD Profile uses the "entry" type parameter.

13. Publishing Controls - NOT USED

14. Securing the Atom Publishing Protocol

The SWORD Profile adheres to the statement: "At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]."

It is the responsibility of implementers to integrate existing authentication solutions.

15. Security Considerations

The SWORD Profile recommends implementers refer to this section of APP.

Compliance

Compliance to APP and ATOM

The SWORD profile adds extensions to the APP to support a particular set of requirements for offering 'deposit' services. Update, delete and listing collections are out of scope for SWORD. Implementers of the SWORD profile of APP SHOULD aim to support all of the mandatory elements of APP. Implementers MAY wish to support additional APP functions and should refer to the APP [ATOMPUB] specification for further details.

SWORD Compliance

SWORD identifies two levels of compliance.

Level 0 requires implementation of a minimal set of mandatory elements as defined below.

Full level 1 compliance REQUIRES implementation of the full set of extension elements and compliance with APP [ATOMPUB] as indicated by the SWORD profile of APP specified in this document.

Implementers MUST as a minimum implement the APP [ATOMPUB] sufficiently to support SWORD Level 0 Compliance. It is RECOMMENDED that implementers support Level 1 Compliance.

Level 0 compliance

Compliance to SWORD level 0 REQUIRES the use of only one sword 'extension' element, <sword:level>. This is used to indicate the compliance level. In more general terms, it indicates that the APP implementation is cognisant of the SWORD profile.

Mandatory elements for Level 0 compliance are listed below; M indicates mandatory APP/ATOM elements:

SWORD parameter APP element Extension In
Collection ID (M) <app:collection href=""> (atom uri) Service Document
Deposit Status (M) HTTP Status Code HTTP Response
Error Code (M) HTTP Status Code HTTP Response
Error Description with HTTP status code HTTP Response
Target Collection (M) POST to URI of Collection
Identifier (URI) (M)

Location:

HTTP header (response>
Transaction/deposit ID (M) <atom:id> Atom Entry Document (response)
Server Level <sword:level> Service Document

Level 1 compliance

These elements are mandatory for full level 1 compliance and optional for partial compliance; ; M indicates mandatory APP/ATOM elements:.

SWORD parameter APP element / HTTP header Extension APP / HTTP header In
Repository / Collection Name

<app:collection>
<atom:title>

Service Document
Repository / Collection Policy

<sword:collectionPolicy>

Service Document
Collection Description

<dcterms:abstract>

Service Document
Accepted formats <app:accept> Service Document
Format Namespace <sword:formatNamespace> Service Document
Format Namespace X-Format-Namespace HTTP header (POST)
HTTP header (response)
Treatment Description

<sword:treatment>

Service Description
Atom Entry Document (response)
Mediation Allowed

<sword:mediation>

Service Document
Source Repository or Client

<atom:source>
<atom:generator>

Atom Entry Document (response)
Checksum Content-MD5: md5-digest HTTP header (POST)
On Behalf Of X-On-Behalf-Of GET Service Document
HTTP header (POST)
On Behalf Of <atom:contributor> Atom Entry Document (response)
Object URI (M)

<atom:content src="">

Atom Entry Document (response)
Display URI <atom:link rel="edit" href""> Atom Entry Document (response)
Transaction/deposit ID (M) The Slug:

<atom:id> (M at Level 0)

HTTP header (POST)
Atom Entry Document (response)
Depositor <atom:author> (M) Atom Entry Document (response)
Date of deposit <atom:atom:updated>(M) Atom Entry Document (response)
Filename of the original deposit Content-Disposition HTTP header (POST)
HTTP header (response)

Optional developers compliance

The following elements are optional.

SWORD parameter APP element / HTTP header Extension APP / HTTP header In
Verbose Supported

<sword:verbose>

Service Description
NoOp Supported

<sword:noOp>

Service Description
Verbose

X-Verbose

HTTP header (POST)
Verbose Description

<sword:verboseDescription>

Atom Entry Document (response)
NoOp X-No-Op HTTP header (POST)

SWORD Conventions

SWORD RECOMMENDS that the APP implementation is accessed from /app (e.g. www.myrepository.ac.uk/app)

SWORD RECOMMENDS that the service document is is accessed from /app/servicedocument (e.g. www.myrepository.ac.uk/app/servicedocument)

Authentication and Mediation

There are four possible use cases for mediated and non-mediated deposit:

  1. unauthenticated POSTs
  2. authenticated POSTs by the author/owner, i.e. that don't use X-On-Behalf-Of
  3. authenticated POSTs that use X-On-Behalf-Of, and the authenticated user is a "Person construct" (meditated deposit)
  4. authenticated POSTs that use X-On-Behalf-Of, but where the authenticated user is not a "Person construct" (mediated deposit)

For case (2), the <atom:author> element MAY be used to capture a name or username for the authenticated user (the depositor). For case (3), the <atom:author> element MAY be used to capture a name or username for the authenticated user (the depositor) and the <atom:contributor> element MAY be used to capture a name or username for the user on-behalf-of whom that deposit is being made. For full level 1 compliance these are mandatory. For case (4) the <atom:author> and <atom:contributor> elements are not mandatory, although implementers should note that <atom:author> is mandatory for ATOM compliance. In this case, implementers may choose to populate these elements.

In the SWORD Profile, author and contributor relate to the 'deposit', not to the package being deposited, i.e. the author refers to the person making the deposit, not to the author of the package.

In cases (1) to (4), the <atom:generator> element MAY be used to indicate the repository or client making the deposit. This is mandatory for full level 1 compliance, in which case the value of <atom:generator> "MUST be a string that is a human-readable name for the generating agent". The uri attribute SHOULD be used to supply the uri of the repository/client. Use of the version attribute is optional.

Also see section 14. Securing the Atom Publishing Protocol.

SWORD Extensions to the APP

This section defines SWORD extensions to the APP, as used in this document.

APP Element extensions

SWORD defines the use of additional elements, as follows:

Element Namespace APP / ATOM extension point Usage notes
<sword:collectionPolicy>
http://purl.org/net/sword/ <app:collection> (Service Document) Use for a human-readable repository or collection policy.  Include either a text description or a URI.
<dcterms:abstract> http://purl.org/dc/terms/ <app:collection> (Service Document) Use for a human-readable repository or collection description.  Include either a text description or a URI.
<sword:mediation>

http://purl.org/net/sword/

<app:collection> (Service Document) Use to indicate if mediated deposit is allowed on the defined collection.
Value=true|false
<sword:treatment>

http://purl.org/net/sword/

<app:collection> (Service Document) Use for a human-readable statement about what treatment the deposited resource will receive. Include either a text description or a URI.
<sword:treatment>

http://purl.org/net/sword/

<atom:entry> (Atom Entry Document (response)) Use for a human-readable statement about what treatment the deposited resource has received. Include either a text description or a URI.
<sword:verbose>

http://purl.org/net/sword/

<app:service> (Service Document) Use to indicate if verbose descriptions are supported. This extension is intended for use by developers for testing implementation.
Value=true|false
<sword:verboseDescription>

http://purl.org/net/sword/

<atom:entry> (Atom Entry

Document

(response))
Use to supply a verbose description. This extension is intended for use by developers for testing implementation. Include either a text description or a URI.
Value=true|false
<sword:noOp>

http://purl.org/net/sword/

<app:service> (Service Document) Use 'true' to indicate if the server supports the noOp facility. This extension is intended for use by developers for testing implementation.
Value=true|false
<sword:noOp>

http://purl.org/net/sword/

<atom:entry> (Atom Entry Document (response)) Use 'true' to indicate that the server has taken no action on receipt of this deposit. This extension is intended for use by developers for testing implementation.
Value=true|false
<sword:formatNamespace>

http://purl.org/net/sword/

<app:collection> (Service Document) Used to supply a URI for the format namespace. See SWORD formats
<sword:level> http://purl.org/net/sword/ <app:service> (Service Document) Used to indicate the compliance level supported by the server.
Value=0|1

HTTP Header extensions

Header Usage Usage notes
Content-MD5 HTTP Header (POST) Used to supply a MD5 checksum. See RFC 2616.
Content-Disposition HTTP Header (POST) Used to supply the filename of the deposited file. See RFC 2183.
X-On-Behalf-Of HTTP Header (POST) Used to supply the username of the target owner for the deposit, on whose behalf the authenticated user is making the deposit.
X-Format-Namespace HTTP Header (POST) Used for a the identifier for a namespace for the particular packaging format supplied.
X-Verbose HTTP Header (POST) Use to request a verbose description with the response. This header

is intended for use by developers for testing implementation.

Value=true|false
X-No-Op HTTP Header (POST) Use 'true' to indicate if the server should take no action on receipt of this deposit.  This extension is intended for use by developers for testing implementation.
Value=true|false
X-Error-Code HTTP Header (response) Used in conjunction with 4xx or 5xx error codes, to provide additional information about the error:
  • ErrorContent - where the supplied format is not the same as that identified in the X-Format-Namespace and/or that supported by the server
  • ErrorChecksumMismatch - required if a checksum is sent
  • ErrorBadRequest - where parameters are not understood
  • TargetOwnerUnknown - where the server cannot identify the specified TargetOwner
  • MediationNotAllowed - where a client has attempted a mediated deposit, but this is not supported by the server

Examples

Retrieve Service Document

GET to Service Document (simple user)

GET /app/servicedocument HTTP/1.1
Host: www.myrepository.ac.uk

GET to Service Document onBehalfOf TargetUser (mediated user)

GET /app/servicedocument HTTP/1.1
Host: www.myrepository.ac.uk
X-On-Behalf-Of: lcarr

Service Document

Example 1: level 0

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
         xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sword="http://purl.org/net/sword/">
 <sword:level>0</sword:level>  
 <workspace>
   <atom:title>Main Site</atom:title>
   <collection
       href="http://www.myrepository.ac.uk/atom/geography-collection" >
     <atom:title>My Repository : Geography Collection</atom:title>
   </collection>
 </workspace>
</service>


Example 2: level 1

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app#"
         xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sword="http://purl.org/net/sword/"
	 xmlns:dcterms="http://purl.org/dc/terms/">
 <sword:level>1</sword:level>
 <sword:verbose>true</sword:verbose>
 <sword:noOp>true</sword:noOp>  
 <workspace>
   <atom:title>Main Site</atom:title>
   <collection
       href="http://www.myrepository.ac.uk/atom/geography-collection" >
     <atom:title>My Repository : Geography Collection</atom:title>
     <app:accept>application/xml</app:accept>
     <app:accept>application/zip</app:accept>
     <app:accept>application/atom+xml</app:accept> 
     <sword:collectionPolicy>Collection Policy</sword:collectionPolicy>
     <dcterms:abstract>Collection description</dcterms:abstract>
     <sword:mediation>true</sword:mediation>
     <sword:treatment>treatment description</sword:treatment>
     <sword:formatNamespace>uri</sword:formatNamespace>
   </collection>
 </workspace>
</service>

Deposit

Example 1: POST binary (level 0)

http://www.myrepository.ac.uk/atom/geography-collection
   POST /geography-collection/ HTTP/1.1
   Host: www.myrepository.ac.uk/app
   Content-Type: application/zip
   Content-Length: nnn
  
   ...binary data...

Example 2: POST binary (mediated user)

  POST /geography-collection HTTP/1.1
  Host: www.myrepository.ac.uk/app
  Content-Type: application/zip
  Authorization: Basic ZGFmZnk6c2VjZXJldA==
  Content-Length: nnn
  X-On-Behalf-Of: lcarr
   
  ...binary data...

Example 3: POST (level 1, mediated user)

  POST /geography-collection HTTP/1.1
  Host: www.myrepository.ac.uk/app
  Content-Type: application/zip
  Slug: deposit-id
  Authorization: Basic ZGFmZnk6c2VjZXJldA==
  Content-Length: nnn
  Content-MD5: md5-digest
  Content-Disposition: filename=mydeposit.zip
  X-On-Behalf-Of: lcarr
  X-Verbose: true
  X-No-Op: true
  X-Format-Namespace: agreed-format-namespace

Response

Example 1: level 0 response

  HTTP/1.1 201 Created
  Date: Mon, 14 May 2007 14:27:11 GMT
  Content-Length: nnn
  Content-Type: application/atom+xml; charset="utf-8"
  Location: http://www.myrepository.ac.uk/collection/edit/my_deposit.atom
  <?xml version="1.0"?>
   <entry xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sword="http://purl.org/net/sword/">
     <title>My Deposit</title>
     <id>deposit-id</id>
     <updated>2007-05-14T14:27:08Z</updated>
     <author><name>lcarr</name></author>
     <summary type="text" />
     <content type="application/zip"
        src="http://www.myrepository.ac.uk/my_deposit.zip"/>
     <link rel="edit-media"
        href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit" />
     <link rel="edit"
        href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit.atom" />
     <sword:treatment>Treatment description</sword:treatment>
  </entry>

Example 2: mediated user

  HTTP/1.1 201 Created
  Date: Mon, 14 May 2007 14:27:11 GMT
  Content-Length: nnn
  Content-Type: application/atom+xml; charset="utf-8"
  Location: http://www.myrepository.ac.uk/collection/edit/my_deposit.atom
  <?xml version="1.0"?>
   <entry xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sword="http://purl.org/net/sword/">
     <title>My Deposit</title>
     <id>deposit-id</id>
     <updated>2007-05-14T14:27:08Z</updated>
     <author><name>mmorrey</name></author>
     <summary type="text" />
     <content type="application/zip"
        src="http://www.myrepository.ac.uk/my_deposit.zip"/>
     <link rel="edit-media"
        href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit" />
     <link rel="edit"
        href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit.atom" />
     <contributor><name>lcarr</name></contributor>
     <source>
          <generator uri"http://www.myrepository.ac.uk/sword/" version="1.0">
           SWORD @ My Repository</generator>
     </source>
     <sword:treatment>Treatment description</sword:treatment>
  </entry>

Example 3: level 1 response

  HTTP/1.1 201 Created
  Date: Mon, 14 May 2007 14:27:11 GMT
  Content-Length: nnn
  Content-Type: application/atom+xml; charset="utf-8"
  Content-MD5: md5-digest
  Content-Disposition: mydeposit.zip   
  Location: http://www.myrepository.ac.uk/collection/edit/my_deposit.atom
  <?xml version="1.0"?>
   <entry xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sword="http://purl.org/net/sword/">
     <title>My Deposit</title>
     <id>deposit-id</id>
     <updated>2007-05-14T14:27:08Z</updated>
     <author><name>mmorrey</name></author>
     <summary type="text" />
     <content type="application/zip"
        src="http://www.myrepository.ac.uk/my_deposit.zip"/>
     <link rel="edit-media"
        href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit" />
     <link rel="edit"
        href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit.atom" />
     <contributor><name>lcarr</name></contributor>
     <source>
          <generator uri"http://www.myrepository.ac.uk/sword/" version="1.0">
           SWORD @ My Repository</generator>
     </source>
     <sword:treatment>Treatment description</sword:treatment>
     <sword:verboseDescription>description</sword:verboseDescription>
     <sword:noOp>true</<sword:noOp>
    <sword:formatNamespace>http://www.loc.gov/METS_Profile/</sword:formatNamespace>>
  </entry>

References

[RFC4387] Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005. [RFC4287]. http://www.ietf.org/rfc/rfc4287.txt (see also non-normative html version at http://APP.org/rfc4287.html)

[ATOMPUB] Gregario, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007. http://www.ietf.org/rfc/rfc5023.txt (see also non-normative html version at http://bitworking.org/projects/atom/rfc5023.html)

[RFC2616] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 http://www.w3.org/Protocols/rfc2616/rfc2616.html

[RFC2616-10] "HTTP/1.1: Status Code Definitions", part of "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2616 Fielding, et al. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[RFC3864] Klyne, G., Nottingham, M. and Mogul, J. "Registration Procedures for Message Header Fields", RFC 3864, September 2004 http://www.rfc-editor.org/rfc/rfc3864.txt

[RFC2183] Troost, R., Dorner, S. and Moore, K., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997 http://www.ietf.org/rfc/rfc2183.txt