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.
Audience:
Application/framework developers?
Managers/stakeholders?
Fedora committers?
?
Purpose:
Allow the community to make decisions about aspects of fedora’s current API that are outside of any specification?
Breaking changes due to alignment with the specification (e.g. drop support for “snapshot” versioning, move to memento-based versioning in spec)
Deprecating features completely
Keeping features that are outside any specification, but allowable
Allow the development of timelines for implementing specific breaking changes in the current Fedora impl?
Aid in communicating “what’s changing” to the community?
Aid in evaluating the proposed Fedora specification?
Allow application developers to identify what they need to do (if anything) to update their applications so that they work with Fedora instances that follow the new specification?
Allow application developers to identify which not-specified-but-allowable behaviors unique to the the current Fedora implementation their application relies on?
.. and either move away from them, or acknowledge and affirm them?
Outcomes:
High-level overview document?
Detailed/comprehensive section-by-section comparison with specs?
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