Skip to content

Commit

Permalink
Move Atomic Batch Operations into its own specification.
Browse files Browse the repository at this point in the history 
* Partially resolves fcrepo/fcrepo-specification#76
  • Loading branch information
@ruebot
ruebot committed Mar 23, 2017
1 parent b14322b commit 880816b
Show file tree
Hide file tree
Showing 3 changed files with 192 additions and 0 deletions.
4 changes: 4 additions & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
*~
*.swp
.DS_Store

9 changes: 9 additions & 0 deletions .travis.yml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
language: java
jdk:
- oraclejdk8

install:
- pip install --user html5validator

script: html5validator

179 changes: 179 additions & 0 deletions index.html
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,179 @@
<!DOCTYPE html>
<html lang="en">
<head>
<title>Fedora Atomic Batch Operations Specification</title>
<meta charset='utf-8'>
<meta name="description" content="Fedora Atomic Operations Specification">
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "unofficial",
shortName: "fedora-abo",
includePermalinks: true,
editors: [
{ name: "Ben Armintor",
company: "Columbia University",
companyURL: "http://library.columbia.edu/"},
{ name: "Aaron Birkland",
company: "Johns Hopkins",
companyURL: "http://www.library.jhu.edu/"},
{ name: "Aaron Coburn",
company: "Amherst College",
companyURL: "https://www.amherst.edu/"},
{ name: "Sergio Fernández",
company: "Redlink",
companyURL: "http://redlink.co/"},
{ name: "Tom Johnson",
company: "Digital Public Library of America",
companyURL: "https://dp.la/"},
{ name: "Nick Ruest",
company: "York University",
companyURL: "http://www.library.yorku.ca"},
{ name: "Rob Sanderson",
company: "The Getty Trust",
companyURL: "http://www.getty.edu/"},
{ name: "Bethany Seeger",
company: "Amherst College",
companyURL: "https://www.amherst.edu/library"},
{ name: "Adam Soroka",
company: "University of Virginia",
companyURL: "https://www.virginia.edu/"},
{ name: "Simeon Warner",
company: "Cornell University",
companyURL: "http://www.cornell.edu/"},
{ name: "Joshua Westgard",
company: "University of Maryland",
companyURL: "http://www.lib.umd.edu/"},
{ name: "Jared Whiklo",
company: "University of Manitoba",
companyURL: "http://umanitoba.ca"},
{ name: "Andrew Woods",
company: "DuraSpace",
companyURL: "http://duraspace.org/"}
],
edDraftURI: "https://fcrepo.github.io/fcrepo-specification/",
testSuiteURI: "https://github.com/fcrepo/fcrepo-tcks",
wg: "Fedora Specification Working Group",
wgURI: "https://wiki.duraspace.org/display/FEDORAAPI/Fedora+Specification",
wgPublicList: "https://groups.google.com/forum/#!forum/fedora-community",
otherLinks: [{
key: "Repository",
data: [
{
value: "Github",
href: "https://github.com/fcrepo/fcrepo-specification"
},
{
value: "Issues",
href: "https://github.com/fcrepo/fcrepo-specification/issues"
},
{
value: "Commits",
href: "https://github.com/fcrepo/fcrepo-specification/commits"
}
]
}],
maxTocLevel: 3,
logos: [{src: "http://fedora.info/assets/fedora_logo.png"}],
overrideCopyright: "<p class='copyright'>This document is licensed under a <a class='subfoot' href='https://creativecommons.org/licenses/by/4.0/' rel='license'>Creative Commons Attribution 4.0 License</a>.</p>"
};
</script>
</head>
<body>
<section id='abstract' class='informative'>
</section>
<section id="conformance">
</section>
<section id="terminology">
</section>
<section id ="atomic-operations">
<h2>Atomic Operations</h2>

<section id="atomic-operations-introduction" class="informative">
<h2>Introduction</h2>
<p>
Fedora provides factilities by which to conduct multiple operations against a repository
in an atomic fashion. This is accomplished by the use of headers on requests. An atomic
series of operations should not require any more requests than the same series of
operations performed non-atomically.
</p>
</section>

<section id="begin">
<h2>Beginning an atomic series of operations</h2>
<p>
A client begins an atomic series of requests by sending any request to any resource with
the header <code>Atomic-Start</code>. The server MUST respond by including a header
<code>Atomic-ID</code> with a unique identifier for the series. The effect of the
request, if it has one, and if the request is successful, MUST be visible to clients
using that identifier to add to this series of requests, as described
<a href="#adding">below</a>, until the series expires or is finished. The effect of the
request, if it has one, and if the request is successful, SHOULD NOT be visible to
clients not using that identifier to add to this series of requests. The effect of the
request MUST NOT be durable unless and until the series is successfully
<a href="#commit">finished</a>.
</p>
</section>

<section id="adding">
<h2>Adding to an atomic series of operations</h2>
<p>
A client adds to an atomic series of requests by sending any request to any resource with
the header <code>Atomic-ID</code> and the identifier for that series. The effect of the
request, if it has one, and if the request is successful, MUST be visible to clients
using that identifier to add to this series of requests, until the series expires or is
finished. The effect of the request, if it has one, and if the request is successful,
SHOULD NOT be visible to clients not using that identifier to add to this series of
requests. The effect of the request MUST NOT be durable unless and until the series is
successfully <a href="#commit">finished</a>. An implementation MUST respond
to any request with multiple <code>Atomic-ID</code> headers with different values or
with an <code>Atomic-ID</code> header with a value that has not been assigned to a
series or that has expired (see <a href="#expiration">below</a>) with a 409 response.
That response MUST include an <code>Atomic-Invalid</code> header or headers with the
invalid identifier or identifiers.
</p>
</section>

<section id="expiration">
<h2>Expiration</h2>
<p>
An implementation MAY enforce automatic expiration for an atomic series of requests.
If so, the response to any request made as part of the series MUST have a
<code>Atomic-Expires</code> header with the HTTP datetime at which the series will
expire. An implementation MAY extend the lifetime of a series upon the receipt of any
request specifying the unique identifier of that series in the <code>Atomic-ID</code>
header.
</p>
</section>

<section id="commit">
<h2>Committing a series</h2>
<p>
A client can finish an atomic series of requests by sending any
<code>PUT</code>/<code>POST</code>/<code>PATCH</code>/<code>DELETE</code> request
including both a <code>Atomic-Commit</code> header and a <code>Atomic-ID</code>
header with the unique identifier of an existing series. The effects of all requests
in the series MUST become durable and MUST become visible to all clients. The unique
identifier of the series MUST be expired and MUST NOT be reused.
</p>
</section>

<section id="abort">
<h2>Aborting a series</h2>
<p>
A client can finish an atomic series of requests by sending any request including
both a <code>Atomic-Abort</code> header and a <code>Atomic-ID</code> header with
the unique identifier of an existing series. The effects of all requests in the
series MUST disappear to all clients, and MUST be durably gone. The unique identifier
of the series MUST be expired and MUST NOT be reused.
</p>
</section>
</section>
<section class='appendix'>
<h2>Acknowledgments</h2>
<p>
</p>
</section>
</body>
</html>

0 comments on commit 880816b

Please sign in to comment.