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

1. External Binary Content
   1. Spec: Must advertise support in the Accept-Post response header for each supported type parameter of supported Content-Type values (url and local-file)
   2. 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

      1. 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

   3. 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.
      1. Modeshape impl: Add support for Want-Digest on external content
   4. 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.
      1. Modeshape impl: add support for Content-Location header on external content
   5. 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
      1. 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

See: https://github.com/fcrepo/fcrepo-specification/issues?q=is%3Aissue+is%3Aopen+label%3Atopic-authorization

1. Modeshape impl: supports acl:Read and acl:Write 
   1. Spec: Also includes support for acl:Append and acl:Control
   2. https://github.com/fcrepo/fcrepo-specification/issues/170
      
2. Modeshape impl: uses 'acl:agent foaf:Agent' to denote public access
   1. Spec: uses 'acl:agentClass foaf:Agent' to denote public access
   2. https://github.com/fcrepo/fcrepo-specification/issues/169
3. Modeshape impl: uses acl:agentClass to reference foaf:Group containing foaf:member(s)
   1. Spec: uses acl:agentGroup to reference vcard:Group containing vcard:hasMember(s)
   2. https://github.com/fcrepo/fcrepo-specification/issues/167
4. Modeshape impl: uses strings or URIs for acl:Agent objects
   1. Spec: uses WebIDs, but we will specify the use of URIs for acl:Agent objects
   2. https://github.com/fcrepo/fcrepo-specification/issues/166
5. Modeshape impl: if an ACL is not defined on a given resource, the ACL on the closest parent container is applied
   1. Spec: has the same functionality only if an ACL on a parent is marked with acl:defaultForNew
   2. https://github.com/fcrepo/fcrepo-specification/issues/164

Messaging