This page describes an effort to produce a “delta” document (or documents?) that characterize the differences between the API exposed by the current community Fedora implementation, and the draft Fedora specification.
Specified Delta in Capabilities
CRUD / LDP
- External Binary Content
- Spec: Must advertise support in the Accept-Post response header for each supported type parameter of supported Content-Type values (url and local-file)
- Spec: requests that would create or update a LDP-NR with a message/external-body with an unsupported access-type parameter must respond with HTTP 415 UNSUPPORTED MEDIA TYPE
For example, the following should return a 415:
curl -XPUT -H"Content-Type: message/external-body; access-type=ftp; NAME=\"/some/file\"; site=\"example.com\"" -i localhost:8080/rest/external
- Spec: Fedora servers receiving requests that would create or update a LDP-NR with a message/external-bodymust not accept the request if it cannot guarantee all of the response headers required by the LDP-NR interaction model in this specification.
- Modeshape impl: Add support for Want-Digest on external content
- Spec: LDP-NR GET and HEAD responses should include a Content-Location header with a URI representation of the location of the external content if the Fedora server is proxying the content.
- Modeshape impl: add support for Content-Location header on external content
- Spec: Requests that would create or update a LDP-NR with a message/external-body content type should respect the expiration parameter, if present, by copying content
- Modeshape impl: add support for copying content into the repository when "expiration" parameter is present in create/update requests
Versioning
Fixity
Transmission Fixity
- Summary: No change.
- Modeshape impl: Add a Digest header to content uploads. The server compares the digest to the uploaded content's digest, and if they do not match, it will discard the content and return a 409 Conflict error status.
- Spec: Same
Persistence Fixity
- Summary: The exact mechanism has changed, but the basic approach is similar.
- Modeshape impl: Add "/fcr:fixity" to the end of a binary URL (advertised in the binary description with a triple with the predicate fedora:hasFixityService). The response RDF will contain one or more triples with the predicate premis:hasEventOutcome, and the object "SUCCESS" on success, and "BAD_CHECKSUM" and/or "BAD_SIZE" on failure.
- Spec: A HEAD or GET request to a binary with the Want-Digest header triggers a fixity check. The response will include a Digest header with the computed checksum. The client will need to compare the digest to the stored value.
Authorization
- Modeshape impl: supports acl:Read and acl:Write
- Spec: Also includes support for acl:Append and acl:Control
- https://github.com/fcrepo/fcrepo-specification/issues/170
- Modeshape impl: uses 'acl:agentClass foaf:Agent' to denote public access
- Spec: uses 'acl:agent foaf:Agent' to denote public access
- https://github.com/fcrepo/fcrepo-specification/issues/169
- Modeshape impl: uses acl:agentClass to reference foaf:Group containing foaf:member(s)
- Spec: uses acl:agentGroup to reference vcard:Group containing vcard:hasMember(s)
- https://github.com/fcrepo/fcrepo-specification/issues/167
- Modeshape impl: uses strings or URIs for acl:Agent objects
- Spec: uses WebIDs, but we will specify the use of URIs for acl:Agent objects
- https://github.com/fcrepo/fcrepo-specification/issues/166
- Modeshape impl: if an ACL is not defined on a given resource, the ACL on the closest parent container is applied
- Spec: has the same functionality only if an ACL on a parent is marked with acl:defaultForNew
- https://github.com/fcrepo/fcrepo-specification/issues/164