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 |
---|
|
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
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 | ||||||||
Expand | ||||||||
---|---|---|---|---|---|---|---|---|
4.1 Versioned Resources4.1.1 HTTP GET (Danny Bernstein) (LDPRv) Accept-Datetime header is used to request a past state, exactly as per [RFC7089] section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRmAccept-Datetime value, an implementation should return a 406 (Unacceptable).
GET request on an LDPRv must include the following headers:rel="original timegate" link in the Link header referencing itself<http://mementoweb.org/ns#TimeGate>; rel="type" link in the Link header<http://mementoweb.org/ns#OriginalResource>; rel="type" link in the Link headerrel="timemap" link in the Link header referencing an associated LDPCvVary: Accept-Datetime header, exactly as per [RFC7089] section 2.1.2.4.1.2 HTTP PUT (Danny Bernstein)
4.2 Version Resources
4.2.1 HTTP GET §
4.2.2 HTTP OPTIONS §
4.2.3 HTTP POST
4.2.4 HTTP PUT
4.2.5 HTTP PATCH
4.2.6 HTTP DELETE
4.3 Version Containers (LDPCv)
4.3.1 HTTP GET
4.3.2 HTTP OPTIONSAllow: GET, HEAD, OPTIONS as per [LDP].Allow: DELETE if the versioning behavior is removable by deleting the LDPCv. See 4.3.4HTTP DELETE for requirements on DELETE if supported.Allow: PATCH if the LDPCv has mutable properties. See 3.7.1 Containment Triples for requirements on PATCH if supported.Allow: POST if versions can be explicitly minted by a client. See 4.3.3 HTTP POST for requirements on POST if supported.4.3.3 HTTP POSTPOST , a POST that does not contain a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of the POST . Any request body must be ignored.POST , a POST with a Memento-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 the Memento-Datetime request header.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
4.4 VaryNon-normative note: When a 4.5 Implementation PatternsNon-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 support 4.5.1 Server-Managed Version Creation §Non-normative note: Upon 4.5.2 Client-Managed Version Creation §Non-normative note: An LDPRm for a particular LDPRv is created on 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 the |
5 Resource Authorization
Leads
Expand |
---|
5. Resource Authorization §
5.1 ACLs are LDP RDF Sources §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 |
---|
empty |
7 Binary Resource Fixity
Lead
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
|
Expand |
7.1 What is fixity?7.2 Transmission Fixity
|