Tickets Completed
Ticket to Specification Tracking
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 | Can be worked now | Sprint | Depends on | Notes |
|---|---|---|---|---|---|---|---|---|---|
| Duplicate headers when GETting binaries | 1 | 1 | 1 | x | |||||
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 | x | ||||
| HTTP Head does not return the same headers as if the request were a GET | 3.3 | 3 | 1 | 1 | x | ||||
| POSTing a LDP-NR does not return correct constrainedBy Link header | 3.5 | 2 | 1 | 1 | x | ||||
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 Using PATCH it is currently possible to add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource. This should fail with a 409. | 3.6, 3.7.1 | 1 | 3 | 3 | x | Behavior or Direct and Indirect containers must be verified once these two tickets have been resolved. | |||
Replace current Link rel="type" Header with memento specified link (i.e. http://mementoweb.org/ns#OriginalResource) | 4.1 | 1 | 1 | 1 | x | ||||
The If no LDPRm is appropriate to the | 4.1.1 | 1 | 2 | 2 | x | LDPm GET | |||
The response to a
| 4.1.1 | 1 | 1 | 1 | x | ||||
LDPm GET
| 4.2.1 | 1 | 3 | 3 | x | LDPCv: POST | This may be complete with the resolution to fcrepo-2617. Needs to be verified. | ||
LPPm OPTIONS
| 4.2.2 | 1 | 1 | 1 | x | LDPm GET | |||
| LDPm: PUT, POST, and PATCH must return 405 method not allowed | 4.2.3-5 | 1 | 1 | 1 | x | LDPm GET | |||
LDPm: DELETE The server is responsible for all behaviors implied by the LDP-containment of the LDPRm. | 4.2.6 | x | This is a MAY: Are we planning to implement? | ||||||
LDPCv : An implementation must support | 4.3.2 | 1 | 2 | 2 | (may be closed - depending on approach to fcrepo-2617) | ||||
| LDPCv: Disallow PUT and PATCH | 4.3.2 | 1 | 1 | 1 | x | ||||
LDPCv: POST
| 4.3.3 | x (2618) | |||||||
LDPCv: DELETE: Delete of an LDPCv must remove the LDPCv and removing the versioning interaction model from the original LDPRv. | 4.3 | 1 | 2 | 2 | x | LDPm GET | Are we planning to support DELETE? | ||
Vary : When an LDPCv supports | 4.4 | 1 | 1 | 1 | x | LDPc POST | |||
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 | 5 | 3 | 2 | |||||
| Create container mementos from body | |||||||||
| Provide separate timemap for binary and description | |||||||||
Create historical binary mementos | |||||||||
| Create binary description mementos | |||||||||
| Ignore referential integrity of memento properties | |||||||||
| Default acls must be defined in accordance with the SOLID WEBAC spec. | 5.0 | 2 | 2 | 2 | x | ||||
Non-normative note: Implementations may set default access controls for all resources by including an ACL for the root container with an authorization that applies to access by any agent (acl:agentClass foaf:Agent), applies to any resource (acl:accessToClass ldp:Resource), and is defined to be inherited (acl:default). The example below grants read access (acl:mode acl:Read) but any combination of modes may be specified. | 5.2 | 1 | 2 | 3 | x | ||||
The interaction pattern for ACL discovery is described in [SOLIDWEBAC] ACL Resource Location Discovery. A conforming server must advertise the individual resource ACL for every controlled resource in HTTP responses with a rel="acl" link in the Link header, whether or not the ACL exists. The ACL resource should be located in the same server as the controlled resource. | 5.3 | 1 | 2 | 2 | x | depends on fcrepo-2688 | |||
The server must reject the request and respond with a 4xx or 5xx range status code, such as 409 (Conflict) if it isn't able to create the LDPR with the specifiedLDP-RS as the ACL. In that response, the restrictions causing the request to fail must be described in a resource indicated by a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header, following the pattern of [LDP] 4.2.1.6. | 5.4 | 1 | 1 | 1 | x | depends on fcrepo-2688 | |||
Restrict Cross Domain ACLs
| 5.5 | 2 | 2 | 2 | x | ||||
| Implement ACL linking on resource creation | 5.4 | 2 | 2 | 2 | x | ||||
| 5.7.1 | 1 | 1 | 1 | x | |||||
| 5.7.1 | 1 | 1 | 1 | depends on fcrepo-2716 | |||||
| 5.7.1,2 | 1 | 1 | 1 | depends on fcrepo-2717 | |||||
| 5.7.3 | 1 | 1 | 1 | depends on fcrepo-2718 | |||||
| |||||||||
| Verify ACL inheritance | 5.9 | JIRAs needed! |
Critical Non-Alignment Issues to be included in the 5.0.0 release
| Jira | Priority | Depends On | Story Points |
|---|---|---|---|
