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:

         Code Block
         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
   6. Ensure 'Accept-Post' header includes 'message/external-body' url and local-file
   7. Respond with 415 code for other access-type values
   8. Ensure all LDP-NR headers are included in external content responses
   9. 'Location' header should include 'Content-Location' with URI of external content
   10. Add support for 'expiration' parameter, to copy content into the repo
       • First step could be 4xx response with 'constrainedby' Link

   3.1.1

   1. NonRDFSource link header must be supported, regardless of Content-Type

   3.2.1

   1. Must allow interaction model to change to subtype of current model
   2. Must disallow PATCH to change ixn model to non-subtype of current model

   3.3

   1. POST creation must return a 'constrainedby' header indicating ixn model

   3.3.1

   1. Ensure that LDP-NR creation requests fail with correct response code
      • 409 for mismatch
      • 400 for unsupported algorithm

   3.4

   1. PUT update of resource must fail with 409 if changing ixn model to non-subtype

   3.5.1

   1. MAY add support for 'PreferContainedDescriptions': not just URIs of contained

   3.5.2

   1. Ensure correct behavior of returning 'Preference-Applied' header

   3.5.3

   1. Add support for 'Want-Digest' header

   3.6

   1. Ensure Digest header is the same of HEAD as GET
   2. Ensure payload headers are omitted on GET (see: rfc7231:section3.3)

   3.7.1

   1. Add support for DEPTH header, values: 0 and infinity
   2. Respond with 400 for other values of DEPTH

Versioning

4.1.2.1

1. Add 'Accept-Datetime' header on LDPRv's, on GET

4.1.2.2

1. Include 'Link: rel="timemap"' on versioned resource pointing to LDPCv, on GET

4.1.3.1

1. PUT on LDPRv creates a new LDPRm in the LDPCv

4.1.3.2

1. PUT request header to support 'Accept-Datetime'

4.1.3.3

1. Include 'Link: rel=timemap' pointing to LDPCv for versioned resources
   
   • On PUT response
   • Also include 'Vary: Accept-Datetime' header in response

4.2.1

1. Creation of versioned resource triggered by 'Link: rel=type' value=VersionedResource
   • An LDPRm is also created

4.2.3

1. TimeGate for LDPRm is LDPRv on GET

4.2.5

1. Include following OPTIONS on LDPRm: GET, HEAD, OPTIONS, DELETE

4.2.6

1. Forbid PATCH on LDPRm

4.2.7

1. Forbid POST on LDPRm

4.2.8

1. Forbid PUT on LDPRm

4.3.1

1. Create LDPCv when versioned resource (LDPRv) is created
   • LDPCv is a TimeMap
2. Must respond to GET 'Accept: application/link-format'
3. LDPCv must not be contained by the LDPRv

4.3.2

1. Delete of LDPRv should also delete the LDPCv
   ? ** remove versioning ixn model from LDPRv? it should be deleted, no?

4.3.3

1. Delete of LDPCv removes versioning ixn model from LDPRv
2. PATCH on LDPCv is allowed
3. POST on LDPCv creates a new LDPRm
   ? ** Should method specifics be in appropriate sections? not in OPTIONS ?

4.3.4

1. PATCH can not modify containment triples

4.3.5

1. POST on LDPCv should indicate no body accepted with 'Accept-Post: /; p-0.0'
2. POST with body should respond with 415 and constrainedby Link
3. LDPRm created on POST to LDPCv should respond with 'Location' header of LDPRm
   ? # "If an LDPCv does accept POST with request body..."? what would that mean?
   • Would this implicitly change the LDPRv?
4. Honor 'Memento-Datetime' header on LDPCv POST

4.4

1. 'Vary' header on LDPCv should be: Vary-Post: Memento-Datetime, Vary-Put: m-dt

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.
• Support Want-Digest on HEAD and GET of LDP-NRs

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 (to be changed to acl:default)
   2. https://github.com/fcrepo/fcrepo-specification/issues/164
6. Modeshape impl: uses 'acl:accessToClass' for targeting all resources with a given rdf:type value
   1. Spec: Do not use acl:accessToClass, per the SOLIDWAC recommendation

Messaging

• Summary: The format for the messages will change to JSON-LD
• https://github.com/fcrepo/fcrepo-adopters-guide/blob/master/docs/messaging.md
  

• 6.1

  1. Emit message for synthetic triples added/removed
  2. Emit message for each resource deleted in a hierarchy
• 6.3
  • The notification serialization must conform to the [activitystreams-core] specification.
  • Wherever possible, data should be expressed using the [activitystreams-vocabulary].
  • Remove use of message headers  (not a spec requirement to mentioned in messaging.md)
  • Examples of messages:
    • minimal: https://fcrepo.github.io/fcrepo-specification/#minimal-notification-example
    • with additional information: https://fcrepo.github.io/fcrepo-specification/#basic-notification-example