Fedora's alignment with each category of the Fedora API Specification needs to be verified for completeness and correctness. Below is a listing of the specification categories, the person/people taking the lead on ensuring alignment, and the current status of alignment.
Legend
Panel |
---|
- Untested |
Environment
- Version of Fedora: 6034a73 https://github.com/fcrepo4/fcrepo4/commit/fe92e09c54949b930a27dbd5f24a591cbd4ed568 (as of 2018-06-12)
- Version of Fedora Specification: https: e6fc281 //github.com/fcrepo/fcrepo-specification/commit/83b3bca9627e5ba9fda5b0c1718bea455747f559 (as of 2018-06-13)
- Test Compatibility Suite
- Legacy - Version of script: 9d20fad (repo and usage here: https://github.com/rotated8/fedora-spec-testing)
...
Expand | ||||||||
---|---|---|---|---|---|---|---|---|
3.1 General (Jared Whiklo)
3.1.1 LDP Containers
3.1.2 LDP-NR creation
3.1.3 Constraints Document
3.2 HTTP PATCH (Jared Whiklo)
3.2.1 Interaction models
3.3 HTTP POST
3.3.1 LDP-NRs
3.4 HTTP PUT
3.4.1 LDP-RSs
3.4.2 LDP-NRs
3.1.4 Data Model
3.2 HTTP GET3.2.1 Additional values for the Prefer header
3.2.2 LDP-RSs
3.2.3 LDP-NRs
3.3 HTTP HEAD
3.4 HTTP OPTIONS (Yinlin Chen)
3.5 HTTP POST
3.5.1 LDP-NRs
3.4.3 Creating resources with6 HTTP PUT
3.5 HTTP GET
3.5.1 Additional values for the Prefer header
3.5.2 LDP-RSs
3.5.3 LDP-NRs
3.6 HTTP HEAD
3.7 HTTP DELETE
3.7.1 Depth header
3.8 External Binary Content
3.8.1 Referenced RDF content in mandataory LDP serializations
3.8.2 Proxied content vs. redirected content
|
4 Versioning
Leads
...
4.1 Versioned Resources
- When an LDPR is created with a
rel="type"
link in theLink
header specifying typehttp://mementoweb.org/ns#OriginalResource
to indicate versioning, it must be created as an LDPRv and a version container (LDPCv) must be created to contain Memento resources (LDPRm) capturing time-varying representations of the LDPRv. Patterns for version creation are described in 4.5 Implementation Patterns.- NB: Spec has changed: currently LDPRv is created using the type http://fedora.info/definitions/fcrepo#VersionedResource in the link header.
4.1.1 HTTP GET (LDPRv)
...
- curl -v -X GET http://localhost:8080/rest/test -H "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT" returns 200.
- (db) Should a post to a non-LDPRv return 406?
...
- NB: Spec has changed: currently LDPRv is returning type http://fedora.info/definitions/fcrepo#VersionedResource
...
4.1.2 HTTP PUT (Danny Bernstein)
- An implementation must support
PUT
, as is the case for any LDPR.
4.2 Version Resources (LDPRm)
- An LDPRm may be deleted;
- however, it must not be modified once created.
4.2.1 HTTP GET §
- An implementation must support
GET
, as is the case for any LDPR. - The headers for
GET
requests and responses on this resource must conform to [RFC7089] section 2.1. Particularly it should be noted that the relevant TimeGate for an LDPRm is the original versioned LDPRv. - In addition, any response to a
GET
request must include a<http://mementoweb.org/ns#Memento>; rel="type"
link in theLink
header.
4.2.2 HTTP OPTIONS §
- An implementation must support
OPTIONS
. - A response to an
OPTIONS
request must includeAllow: GET, HEAD, OPTIONS
as per [LDP]. - An implementation may include
Allow: DELETE
if clients can remove a version from the version history, as noted in 3.8 HTTP DELETE.
4.2.3 HTTP POST
- An implementation must not support
POST
for LDPRms.
4.2.4 HTTP PUT
- An implementation must not support
PUT
for LDPRms.
4.2.5 HTTP PATCH
- An implementation must not support
PATCH
for LDPRms.
4.2.6 HTTP DELETE
- An implementation may support
DELETE
for LDPRms. IfDELETE
is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm.
4.3 Version Containers (LDPCv) (Jared Whiklo)
- An implementation must indicate TimeMap in the same way it indicates the container interaction model of the resource via HTTP headers.
- Currently returns Link: <http://fedora.info/definitions/v4/repository#TimeMap>; rel="type"
- An implementation must not allow the creation of an LDPCv that is LDP-contained by its associated LDPRv.
4.3.1 HTTP GET (Jared Whiklo)
- An implementation must support
GET
, as is the case for any LDPR. Any response to aGET
request must include a<http://mementoweb.org/ns#TimeMap>; rel="type"
link in theLink
header.- Uses the URI in above 4.3 point 1, needs updating
- An LDPCv must respond to
GET Accept: application/link-format
as indicated in [RFC7089] section 5 and specified in [RFC6690] section 7.3. - An implementation must include the
Allow
header as outlined in 4.3.2 HTTP OPTIONS. - If an LDPCv supports
POST
, then it must include theAccept-Post
header described in 4.3.3 HTTP POST.4.3.3 does not reference an
Accept-Post
header.
- If an LDPCv supports
PATCH
, then it must include theAccept-Patch
header.- Accept-Patch it is not mentioned in the spec.
4.3.2 HTTP OPTIONS (Jared Whiklo)
- An implementation must
Allow: GET, HEAD, OPTIONS
as per [LDP]. - An implementation may
Allow: DELETE
if the versioning behavior is removable by deleting the LDPCv. See 4.3.4HTTP DELETE for requirements onDELETE
if supported. - An implementation may
Allow: PATCH
if the LDPCv has mutable properties. See 3.7.1 Containment Triples for requirements onPATCH
if supported.- NB: it does not allow PATCH
- An implementation may
Allow: POST
if versions can be explicitly minted by a client. See 4.3.3 HTTP POST for requirements onPOST
if supported. - Currently PUT is allowed. The spec doesn't explicitly ban it, but perhaps it should?
4.3.3 HTTP POST
- Although an LDPCv is both a TimeMap and an LDPC, it may disallow POST requests.
- If an LDPCv supports
POST
, aPOST
that does not contain aMemento-Datetime
header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of thePOST
. Any request body must be ignored. - If an LDPCv supports
POST
, aPOST
with aMemento-Datetime
header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body and the datetime given in theMemento-Datetime
request header. - If an implementation does not support one or both of
POST
cases above, it must respond to such requests with a 4xx range status code and a link to an appropriate constraints document (see [LDP] 4.2.1.6).
4.3.4 HTTP DELETE
- An implementation may support
DELETE
.- DELETE is advertised, but not currently implemented: do we plan to implement ?
- An implementation that does support
DELETE
should do so by both removing the LDPCv and removing the versioning interaction model from the original LDPRv.
4.4 Vary
Non-normative note: When aPOST
to an LDPCv, or aPUT
orPATCH
to an LDPRv creates a new LDPRm, the response indicates this by using aVary
header as appropriate. When an LDPCv supportsPOST
, and allows clients to specify a datetime for created URI-Ms, Vary-Post/Vary-Put: Memento-Datetime.
4.5 Implementation Patterns
Non-normative note: This section describes the way the normative specification might be applied to implement discoverable versioning patterns. If an implementation of an LDPCv does not supportPOST
to mint versions, that must be advertised viaOPTIONS
as described in 4.3.2 HTTP OPTIONS. This allows a client to perform anOPTIONS
request on an LDPCv to determine if it can explicitly mint versions. If the LDPCv does not supportPOST
, the client should assume some other mechanism is used to mint versions, for example, the implementation may automatically mint versions instead, but that is outside the requirements of this specification. This document specifies normatively only how LDPCvs and LDPRms can be discovered, and how they should act.
4.5.1 Server-Managed Version Creation §
Non-normative note: UponPUT
orPATCH
to an LDPRv, a new LDPRm is created in an appropriate LDPCv. This LDPRm is the version of the original LDPRv that was just created.
4.5.2 Client-Managed Version Creation §
Non-normative note: An LDPRm for a particular LDPRv is created onPOST
to any LDPCv associated with that LDPRv. The new LDPRm is contained in the LDPCv to which thePOST
was made and features in that LDPCv-as-a-TimeMap. This pattern is very flexible and might be useful for migration from other systems into Fedora implementations. Responses from requests to the LDPRv include arel="timemap"
link in theLink
header that references the same LDPCv as per [RFC7089] section 5.
3.6.1 LDP-RSs
3.6.2 LDP-NRs (Danny Bernstein)
3.6.3 Creating resources with HTTP PUT
3.7 HTTP PATCH (Jared Whiklo)
3.7.1 Containment Triples
3.7.2 Interaction models
3.8 HTTP DELETE (Yinlin Chen)
3.8.1 Recursive Delete
3.9 External Binary Content
3.9.1 Advertising External Content Support
3.9.2 External Content for RDF Resources
3.9.3 Redirected and Proxied External Content
|
4 Versioning
Leads
Expand | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
4 Resource Versioning
4.1 Versioned Resources
4.1.1 HTTP GET (LDPRv)
4.1.2 HTTP PUT (LDPRv) (Danny Bernstein)
4.2.1 HTTP GET (LDPRm)
4.2.3 HTTP POST (LDPRm)
4.2.4 HTTP PUT (LDPRm)
4.2.5 HTTP PATCH (LDPRm)
4.2.6 HTTP DELETE (LDPRm)
4.3.1 HTTP GET (LDPCv) (Jared Whiklo)
4.3.2 HTTP OPTIONS (LDPCv) (Jared Whiklo)
4.3.3 HTTP POST (LDPCv) 4.3.3.1 Implementations that allow POSTs for LDPCvs
4.3.3.2 Implementations that disallow POSTs for LDPCvs
4.3.4 HTTP PUT (LDPCv)
4.3.5 HTTP PATCH (LDPCv)
4.3.6 HTTP DELETE (LDPCv)
4.4 Implementation Patterns
|
5 Resource Authorization
Leads
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
5. Resource Authorization
5.1 ACLs are LDP RDF Sources
5.2 ACL Representation and Interpretation (Danny Bernstein)
5.3 ACLs are discoverable via Link Headers
5.4 ACL linking on resource creation (Peter Eichman)
5.5 Cross-Domain ACLs (Peter Eichman)
5.6 Cross-Domain Group Listings
5.7 Append Mode
5.7.1 LDP-RS (Append)
5.7.2 LDPC (Append)
5.7.3 LDP-NR (Append)
5.8 Access To Class
5.9 Inheritance and Default ACLs
|
6 Notifications
Lead
Expand |
---|
6.1 Notification Events
6.2 Notification Serialization
6.3 Examples
|
7 Binary Resource Fixity
Lead
Expand |
---|
7.1 Transmission Fixity
7.2 Persistance Fixity
|
4.5.3 Replacing Contents from Mementos §
Non-normative note: Using the ingest-by-reference mechanism, one can replace the contents of an LDPRvwith that of an LDPRm by providing it's URL as theURL
parameter in aContent-Type: message/external-body
header. For example, given an LDPRm with URLhttp://example.org/some/memento
, the full header would beContent-Type: message/external-body; access-type=URL; expiration=1;
URL="http://example.org/some/memento"
5 Resource Authorization
Leads
Expand |
---|
5. Resource Authorization §
5.1 ACLs are LDP RDF Sources § (Danny Bernstein)5.2 ACL Representation and Interpretation §
5.3 ACLs are discoverable via Link Headers §
5.4 ACL linking on resource creation §
5.5 Cross-Domain ACLs §
5.6 Cross-Domain Group Listings §
5.7 Append Mode §
5.7.1 LDP-RS §
5.7.2 LDPC §
5.7.3 LDP-NR §
5.8 Access To Class §
5.9 Inheritance and Default ACLs §
|
6 Notifications
Lead
Expand |
---|
6.2 Notification Events §
6.3 Notification Serialization §
Each event described by a notification must contain:
Each event described by a notification should contain:
|
7 Binary Resource Fixity
Lead
Expand |
---|
7.1 What is fixity?Example proceedures that may be used to verify fixity:
7.2 Transmission Fixity Digest header (defined in [RFC3230]) in POST
Digest header (defined in [RFC3230]) in PUTfor example, in curl command:
|