The table below is derived from the following document
Fedora API Spec and Delta Document Verification
Issue Description | Spec Reference | Priority | Difficulty | Story Points | Related JIRAs | Sprint | Depends on | Notes |
---|---|---|---|---|---|---|---|---|
Change the PreferInboundReferences URI in Prefer header from http://fedora.info/definitions/v4/repository#InboundReferences to the one defined in the spec (ie http://fedora.info/definitions/fcrepo#PreferInboundReferences) | 3.2.1 | 1 | 1 | 1 | ||||
HTTP Head does not return the same headers as if the request were a GET | 3.3 | 3 | 1 | 1 | ||||
POSTing a LDP-NR does not return correct constrainedBy Link header | 3.5 | 2 | 1 | 1 | ||||
MUST return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
MUST change resource's type if request's type Link is a subtype of resource's current type MUST change resource's interaction model if request's type Link has an LDP interaction model | 3.6 | 1 | 3 | 3 | ||||
Using PATCH it is currently possible to add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource. This should not | 3.7.1 | 1 | 2 | 2 | ||||
Replace current Link rel="type" Header with memento specified link (i.e. http://mementoweb.org/ns#OriginalResource) | 4.1 | 1 | 1 | 1 | ||||
The 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 LDPRm | 4.1.1 | 1 | 2 | 2 | LDPm GET | |||
If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable). | 4.1.1 | 1 | 2 | 1 | ||||
The response to a
| 4.1.1 | |||||||
LDPm GET
| 4.2.1 | 1 | 3 | 3 | find existing | LDPCv: POST | ||
LPPm OPTIONS
| 4.2.2 | 1 | 1 | 1 | LDPm GET | |||
LDPm: PUT, POST, and PATCH must return 405 method not allowed | 4.2.3-5 | 1 | 1 | 1 | LDPm GET | |||
LDPm: DELETE The server is responsible for all behaviors implied by the LDP-containment of the LDPRm. | 4.2.6 | This is a MAY: Are we planning to implement? | ||||||
LDPCv : An implementation must support | 4.3.2 | 1 | 2 | 2 | ||||
LDPCv: Disallow PUT and PATCH | 4.3.2 | 1 | 1 | 1 | ||||
LDPCv: POST
| 4.3.3 | Server Managed Version Creation, Client Managed Version Creation | ||||||
LDPCv: DELETE: Delete of an LDPCv must remove the LDPCv and removing the versioning interaction model from the original LDPRv. | 4.3 | Are we planning to support? | ||||||
Vary : When an LDPCv supports | 4.4 | 1 | 1 | 1 | LDPc POST | |||
Server Managed Version Creation | 4.5.1 | Which one do we plan to support? Both? | ||||||
Client Managed Version Creation | 4.5.2 | ? | ||||||
Replacing Contents from MementosNon-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 | 4.5.3 | Do we plan to support this? And if so due to changes in use of "expiration" the spec will likely change. |
Critical Non-Alignment Issues to be included in the 5.0.0 release
Jira | Priority | Depends On | Story Points |
---|---|---|---|