Fedora API Test Suite Summary

for trellis-ext-db 0.3.0-SNAPSHOT

Req LevelNum PassNum FailNum Skip% Pass
MUST92451867%
SHOULD0000
MAY0000
Total92451867%

Specification SectionReq LevelResultTest DescriptionImplementation Note
3.1.1-A-1MUSTPASSImplementations must support the creation and management of [LDP] Containers.
3.1.1-BMUSTPASSLDP Containers must distinguish [containment triples]
3.1.1-CMUSTPASSLDP Containers must distinguish [membership] triples.
3.1.1-DMUSTPASSLDP Containers must distinguish [minimal-container] triples.
3.1.2-AMUSTPASSImplementations MUST allow the membership constant URI to be set via the ldp:membershipResource property of the content RDF on container creation.
3.1.2-BMUSTFAILImplementations MUST set the ldp:membershipResource by default when not specified on creation.Not required in lieu of 3.1.2-A, per Fedora spec.
3.1.2-G-1MUSTPASSImplementations must allow the membership predicate to be set via either the ldp:hasMemberRelation or ldp:isMemberOfRelation property of the content RDF on container creation, or otherwise default to an implementation defined value. Implementations should use the default <> ldp:hasMemberRelation ldp:member
3.1.2-G-2MUSTPASSImplementations must allow the membership predicate to be set via ldp:isMemberOfRelation property of the content RDF on container creation, or otherwise default to an implementation defined value. Implementations should use the default <> ldp:hasMemberRelation ldp:member
3.1.2-HMUSTFAILImplementations must allow the membership predicate to be set by default to an implementation defined value. Not required in lieu of 3.1.2-G-2, per Fedora spec.
3.1.3-AMUSTPASSImplementations MUST allow the indirect container's membership constant URI to be set via the ldp:membershipResource property of the content RDF on container creation.
3.1.3-BMUSTFAILImplementations MUST set the indirect container's ldp:membershipResource by default when not specified on creation.Not required in lieu of 3.1.3-A, per Fedora spec.
3.1.3-FMUSTPASSImplementations must allow the membership predicate to be set on indirect containers via either the ldp:hasMemberRelation property of the content RDF on container creation.
3.1.3-GMUSTPASSImplementations must allow the membership predicate to be set on indirect containersvia ldp:isMemberOfRelation property of the content RDF on container creation.
3.1.3-HMUSTFAILImplementations must allow the indirect container's membership predicate to be set by default to an implementation defined value. Not required in lieu of 3.1.3-G and 3.1.3-F, per Fedora spec.
3.1.3-NMUSTPASSImplementations must allow the ldp:insertedContentRelation property to be set via the content RDF on container creation
3.1.3-OMUSTFAILImplementations must allow the ldp:insertedContentRelation property to be set by default to an implementation defined value.Not required in lieu of 3.1.3-N, per Fedora spec.
3.1.5-1MUSTPASSWhen implementation choices result in failure to complete a client request, response MUST include a Link header with a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a document. (direct container support)
3.1.5-2MUSTPASSWhen implementation choices result in failure to complete a client request, response MUST include a Link header with a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a document. (indirect container support)
3.10.2-AMUSTSKIPPEDA client may include the X-If-State-Token header field in a PATCH request to make the request conditional on the resource's current state token matching the client's value.
3.10.2-CMUSTSKIPPEDA client may include the X-If-State-Token header field in a PATCH request to make the request conditional on the resource's current state token matching the client's value. An HTTP PATCH request that includes an X-If-State-Token header must be rejected with a 412 (Precondition Failed) response if the implementation supports state tokens, but the client-supplied value does not match the resource's current state token.
3.10.2-DMUSTSKIPPEDA client may include the X-If-State-Token header field in a PUT request to make the request conditional on the resource's current state token matching the client's value.
3.10.2-FMUSTSKIPPEDA client may include the X-If-State-Token header field in a PUT request to make the request conditional on the resource's current state token matching the client's value. An HTTP PUT request that includes an X-If-State-Token header must be rejected with a 412 (Precondition Failed) response if the implementation supports state tokens, but the client-supplied value does not match the resource's current state token.
3.2.2-AMUSTPASSResponses to GET requests that apply a Prefer request header to any LDP-RS must include the Preference-Applied response header as defined in [RFC7240] section 3.
3.2.2-BMUSTPASSWhen a GET request is made to an LDP-RS that describes an associated LDP-NR (3.5 HTTP POST and [LDP]5.2.3.12),the response must include a Link: rel="describes" header referencing the LDP-NR in question, as defined in [RFC6892].
3.2.3-A-1MUSTFAILTesting for supported digest: md5 . GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-A-2MUSTFAILTesting for supported digest: sha . GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-A-3MUSTFAILTesting for supported digest: sha-256 . GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-BMUSTFAILTesting for two supported digests with no weights GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-CMUSTFAILTesting for two supported digests with different weightsGET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-DMUSTFAILTesting for two supported digests with different weights q=0.3,q=0 GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-EMUSTFAILTesting for one supported digest and one unsupported digest.GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230]Trellis does not support the Want-Digest header [RFC3230].
3.2.3-FMUSTFAILTesting that unsupported digest is rejected with a 400.GET requests to any LDP-NR must correctly respond to the Want-Digest header defined in [RFC3230].Trellis does not support the Want-Digest header [RFC3230].
3.3-AMUSTPASSThe HEAD method is identical to GET except that the server must not return a message-body in the response, as specified in [RFC7231] section 4.3.2.
3.3-BMUSTPASSThe server must send the same Digest header in the response as it would have sent if the request had been a GET (or omit it if it would have been omitted for a GET).
3.4-AMUSTPASSAny LDPR must support OPTIONS per [LDP] 4.2.8. 4.2.8.1 LDP servers must support the HTTP OPTIONS method.
3.4-BMUSTPASSAny LDPR must support OPTIONS per [LDP] 4.2.8. LDP servers must indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.
3.5-AMUSTPASSAny LDPC (except Version Containers (LDPCv)) must support POST ([LDP] 4.2.3 / 5.2.3).
3.5.1-AMUSTPASSAny LDPC must support creation of LDP-NRs on POST ([LDP] 5.2.3.3 may becomes must).
3.5.1-BMUSTPASSOn creation of an LDP-NR, an implementation must create an associated LDP-RS describing that LDP-NR ([LDP] 5.2.3.12 may becomes must).
3.5.1-CMUSTFAILAn HTTP POST request that would create an LDP-NR and includes a Digest header (as described in [RFC3230]) for which the instance-digest in that header does not match that of the new LDP-NR must be rejected with a 409 Conflict response.Trellis does not support the Want-Digest header [RFC3230].
3.6.1-AMUSTPASSAny LDP-RS must support PUT to update statements that are not server-managed triples (as defined in [LDP] 2). [LDP] 4.2.4.1 and 4.2.4.3 remain in effect.
3.6.1-BMUSTFAILIf an otherwise valid HTTP PUT request is received that attempts to modify resource statements that a server disallows (not ignores per [LDP] 4.2.4.1), the server must fail the request by responding with a 4xx range status code (e.g. 409 Conflict).Trellis ignores unsupported features in this request, per LDP.
3.6.1-CMUSTFAILThe server must provide a corresponding response body containing information about which statements could not be persisted. ([LDP] 4.2.4.4 should becomes must).Trellis ignores unsupported features in this request, per LDP.
3.6.1-DMUSTFAILIn that response, the restrictions causing such a request to fail must be described in a resource indicated by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [LDP] 4.2.1.6.Trellis ignores unsupported features in this request, per LDP.
3.6.2-AMUSTPASSAny LDP-NR must support PUT to replace the binary content of that resource.
3.6.2-BMUSTFAILAn HTTP PUT request that includes a Digest header (as described in [RFC3230]) for which any instance-digest in that header does not match the instance it describes, must be rejected with a 409 Conflict response.Trellis ignores unsupported features in this request, per LDP.
3.6.3-CMUSTPASSOn creation of an LDP-NR with HTTP PUT, implementations MUST create an associated LDP-RS describing that LDP-NR in the same way that it would when 3.5.1 Creating LDP-NRs with HTTP POST
3.7-AMUSTPASSAny LDP-RS must support PATCH ([LDP] 4.2.7 may becomes must). [sparql11-update] must be an accepted content-type for PATCH.
3.7-CMUSTPASSIf an otherwise valid HTTP PATCH request is received that attempts to modify statements to a resource that a server disallows (not ignores per [LDP] 4.2.4.1), the server must fail the request by responding with a 4xx range status code (e.g. 409 Conflict).
3.7-DMUSTPASSThe server must provide a corresponding response body containing information about which statements could not be persisted. ([LDP] 4.2.4.4 should becomes must).
3.7-EMUSTFAILIn that response, the restrictions causing such a request to fail must be described in a resource indicated by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [LDP] 4.2.1.6.Trellis does not provide a constraints document.
3.7-FMUSTPASSA successful PATCH request must respond with a 2xx status code; the specific code in the 2xx range may vary according to the response body or request state.
3.7.1MUSTPASSThe server should not allow HTTP PATCH to update an LDPC’s containment triples; if the server receives such a request, it should respond with a 409 (Conflict) status code.
3.7.2MUSTFAILThe server must disallow a PATCH request that would change the LDP interaction model of a resource to a type that is not a subtype of the current resource type. That request must be rejected with a 409 Conflict response.Trellis ignores invalid triples, instead of rejecting the whole request.
3.8.1-CMUSTPASSAn implementation must not return a 200 (OK) or 204 (No Content) response unless the entire operation successfully completed.
3.8.1-DMUSTPASSAn implementation must not emit a message that implies the successful DELETE of a resource until the resource has been successfully removed.
3.9-D-1MUSTFAILFedora servers that do not support the creation of LDP-NRs with content external must reject with a 4xx range status codeTrellis does not support external content due to security concerns.
3.9-D-2MUSTFAILFedora servers that do not support the creation of LDP-NRs with content external must describe this restriction in a resource indicated by a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.Trellis does not support external content due to security concerns.
3.9-E-1MUSTSKIPPEDFedora servers must use the handling attribute in the external content link to determine how to process the request. At least one of the following handling attributes must be supported: copy, redirect, and/or proxy.
3.9-E-2MUSTSKIPPEDFedora servers must reject with a 4xx range status code requests for which the handling attribute is not present or cannot be respected.
3.9-E-3MUSTSKIPPEDIn the case that the specified handling cannot be respected, 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.
3.9-F-1MUSTSKIPPEDFedora servers must use the value of the type attribute in the external content link as the media type of the external content, if provided.
3.9-G-1MUSTSKIPPEDA Fedora server receiving requests that would create or update an LDP-NR with content external to the request entity must reject request if it cannot guarantee all of the response headers required by the LDP-NR interaction model in this specification.
3.9.1MUSTSKIPPEDFedora servers supporting external content MUST include "Accept-External-Content-Handling" header in response to "OPTIONS" request.
3.9.3-A-1MUSTSKIPPEDFedora servers supporting "redirect" external content types MUST correctly respond to the "Want-Digest" header.
3.9.3-A-2MUSTSKIPPEDFedora servers supporting "redirect" external content types MUST correctly respond to the "Want-Digest" header.
3.9.3-B-1MUSTSKIPPEDA successful response to a GET request for external content with handling of redirect must have status code of either 302 (Found) or 307 (Temporary Redirect)
3.9.3-B-2MUSTSKIPPEDA successful response to a HEAD request for external content with handling of redirect must have status code of either 302 (Found) or 307 (Temporary Redirect)
4.0-AMUSTFAILWhen an LDPR is created with a rel="type" link in the Link header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, it MUST be created as an LDPRv and a version container (LDPCv) MUST be created to contain Memento resourcesTrellis supports server and not client-managed versioning.
4.1.1-A-2MUSTFAILThe Accept-Datetime header is used to request a past state, exactly as per [RFC7089] section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm.TBD
4.1.1-BMUSTPASSThe response to a GET request on an LDPRv must return a rel="timegate" Link header referencing itself
4.1.1-CMUSTPASSThe response to a GET request on an LDPRv must return a rel="timegate" Link header referencing itself
4.1.1-DMUSTFAILThe response to a GET request on an LDPRv must return a <http://mementoweb.org/ns#OriginalResource>; rel="type" link in the Link header.Trellis does not add redundant <http://mementoweb.org/ns#OriginalResource> headers.
4.1.1-EMUSTFAILThe response to a GET request on an LDPRv must return a <http://mementoweb.org/ns#OriginalResource>; rel="type" link in the Link header.Trellis does not add redundant <http://mementoweb.org/ns#OriginalResource> headers.
4.1.1-FMUSTPASSThe response to a GET request on an LDPRv must return At least one rel="timemap" link in the Link header referencing an associated LDPCv
4.1.1-GMUSTPASSThe response to a GET request on an LDPRv must return a Vary: Accept-Datetime header, exactly as per [RFC7089] section 2.1.2.
4.1.2-AMUSTFAILMust support PUT for creating new LDPRvTrellis supports server and not client-managed versioning.
4.1.2-BMUSTFAILMust support PUT for updating existing LDPRvsTrellis supports server and not client-managed versioning.
4.1.2-CMUSTFAILMust support PUT for creating new LDPNRvTrellis supports server and not client-managed versioning.
4.1.2-DMUSTFAILMust support PUT for updating existing LDPNRvsTrellis supports server and not client-managed versioning.
4.2.1-AMUSTPASSLDPR mementos must support GET
4.2.1-BMUSTPASSLDP-NR mementos must support GET
4.2.1-CMUSTPASSTimeGate for an LDP-RS memento is the original versioned LDP-RS
4.2.1-DMUSTPASSTimeGate for an LDP-NR memento is the original versioned LDP-NR
4.2.1-EMUSTFAILAny response to a GET request on an LDP-RS Memento must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link headerTrellis does not add redundant <http://mementoweb.org/ns#Memento> Link header (not required by Memento specification).
4.2.1-FMUSTFAILAny response to a GET request on an LDP-NR Memento must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link headerTrellis does not add redundant <http://mementoweb.org/ns#Memento> Link header (not required by Memento specification).
4.2.2-AMUSTPASSLDPRm resources must support OPTIONS
4.2.2-BMUSTPASSA response to an OPTIONS request must include Allow: GET, HEAD, OPTIONS
4.2.3MUSTPASSAn LDPRm must not support POST
4.2.4MUSTPASSAn LDPRm must not support PUT
4.2.5MUSTPASSAn LDPRm must not support PATCH
4.2.6MUSTSKIPPEDLDPRm resources must support DELETE if DELETE is advertised in OPTIONS
4.3.1-AMUSTPASSLDPCv must support GET, as is the case for any LDPR
4.3.1-BMUSTFAILLDPCv contain TimeMap type link header.Trellis does not add a special TimeMap link header, since it is redundant.
4.3.1-CMUSTPASSAn LDPCv must respond to GET Accept: application/link-format as indicated in [ RFC7089 ] section 5 and specified in [ RFC6690 ] section 7.3.
4.3.1-DMUSTPASSLDPCv resources must include the Allow header
4.3.1-EMUSTPASSIf an LDPCv supports POST, then it must include the Accept-Post header
4.3.1-FMUSTPASSIf an LDPCv supports PATCH, then it must include the Accept-Patch header
4.3.1-GMUSTFAILAn LDPCv, being a container must have a "Link: <http://www.w3.org/ns/ldp#Container>;rel="type""TimeMap resources in Trellis are not LDP Containers.
4.3.2-AMUSTPASSLDPCv (version containers) MUST support OPTIONS.
4.3.2-BMUSTPASSLDPCv's response to an OPTIONS request MUST include "Allow: GET, HEAD, OPTIONS" per LDP
4.3.2-FMUSTPASSIf an LDPCv supports POST, the response to an OPTIONS request MUST include the "Accept-Post" header
4.3.2-GMUSTPASSIf an LDPCv supports PATCH, the response to an OPTIONS request MUST include the "Accept-Patch" header
4.3.3.1-CMUSTFAILIf an LDPCv of an LDP-RS supports POST, a POST request that does not contain a Memento-Datetime header MUST ignore any request body.TimeMap resources in Trellis are not LDP Containers.
4.3.3.1-DMUSTFAILIf an LDPCv of an LDP-NR supports POST, a POST request that does not contain a Memento-Datetime header MUST ignore any request body.TimeMap resources in Trellis are not LDP Containers.
4.3.3.2MUSTFAILIf an implementation does not support one or both of POST cases above, it must respond to such requests with a 4xx range status code and a link to an appropriate constraints documentTrellis does not provide a constraints document.
5.0-AMUSTPASSAn authorization may list any number of individual agents (that are being given access) by using the acl:agent predicate
5.0-BMUSTPASSAn authorization may list any number of individual agents (that are being given access) by using the acl:agent predicate.
5.0-C-1MUSTPASSTo give access to a group of agents, use the acl:agentGroup predicate. The object of an agentGroup statement is a link to a Group Listing document. The group members are listed in it, using the vcard:hasMember predicate.
5.0-C-2MUSTPASSTo give access to a group of agents, use the acl:agentGroup predicate. The object of an agentGroup statement is a link with a hash URI to a Group Listing document. The group members are listed in it, using the vcard:hasMember predicate.
5.0-DMUSTPASSTo specify that you're giving a particular mode of access to everyone, you can use acl:agentClass foaf:Agent to denote that you're giving access to the class of all agents (the general public).
5.0-EMUSTPASSTo specify that you're giving a particular mode of access to all authenticated users, you can use acl:agentClass acl:AuthenticatedAgent to denote that you're giving access to the class of all authenticated agents.
5.0-FMUSTFAILThe acl:accessTo predicate specifies which resources you're giving access to, using their URLs as the subjects.TBD
5.0-G-1MUSTPASSacl:Read gives access to a class of operations that can be described as "Read Access". In a typical REST API, this includes access to HTTP verbs HEAD.
5.0-G-2MUSTPASSacl:Read gives access to a class of operations that can be described as "Read Access". In a typical REST API, this includes access to HTTP verbs GET.
5.0-HMUSTPASSacl:Read gives access to a class of operations that can be described as "Read Access". In a typical REST API, this includes access to HTTP verbs GET. Its absence must prevent reads
5.0-IMUSTPASSacl:Write gives access to a class of operations that can modify the resource. In a REST API context, this would include PUT.
5.0-JMUSTPASSacl:Write gives access to a class of operations that can modify the resource. In a REST API context, this would include POST.
5.0-KMUSTPASSacl:Write gives access to a class of operations that can modify the resource. In a REST API context, this would include DELETE
5.0-LMUSTPASSacl:Write gives access to a class of operations that can modify the resource. In a REST API context, this would include PATCH.
5.0-M-1MUSTPASSacl:Write gives access to PUT a resource. When not present, writes should be disallowed.
5.0-M-2MUSTPASSacl:Write gives access to POST a resource. When not present, writes should be disallowed.
5.0-M-3MUSTPASSacl:Write gives access to DELETE a resource. When not present, writes should be disallowed.
5.0-M-4MUSTPASSacl:Write gives access to PATCH a resource. When not present, writes should be disallowed.
5.0-NMUSTPASSacl:Append gives a more limited ability to write to a resource -- Append-Only. This generally includes the HTTP verb POST.
5.0-OMUSTFAILacl:Append gives a more limited ability to write to a resource -- Append-Only. This generally includes the INSERT-only portion of SPARQL-based PATCHes.TBD
5.0-PMUSTPASSacl:Append gives a more limited ability to write to a resource -- Append-Only. This generally includes the HTTP verb POST, although some implementations may also extend this mode to cover non-overwriting PUTs, as well as the INSERT-only portion of SPARQL-based PATCHes. Its absence must prevent append updates.
5.0-QMUSTPASSacl:Control is a special-case access mode that gives an agent the ability to view the ACL of a resource.
5.0-RMUSTPASSacl:Control is a special-case access mode that gives an agent the ability to modify the ACL of a resource.
5.0-SMUSTPASSacl:Control is a special-case access mode that gives an agent the ability to modify the ACL of a resource.
5.0-TMUSTPASSacl:Control is a special-case access mode that gives an agent the ability to view and modify the ACL of a resource. Its absence must prevent viewing the ACL.
5.0-UMUSTPASSacl:Control is a special-case access mode that gives an agent the ability to view and modify the ACL of a resource. Its absence must prevent updating the ACL.
5.0-VMUSTPASSacl:Control is a special-case access mode that gives an agent the ability to view and modify the ACL of a resource. Its absence must prevent updating the ACL.
5.1MUSTPASSAn ACL for a controlled resource on a conforming server must itself be an LDP-RS.
5.2-AMUSTPASSImplementations must inspect the ACL RDF for authorizations. Authorizations are identified by type definition triples of the form authorization_N rdf:type acl:Authorization, where authorization_N is the URI of an authorization.
5.2-BMUSTFAILImplementations must use only statements associated with an authorization in the ACL RDF to determine access, except in the case of acl:agentGroup statements where the group listing document is dereferenced.This test may be in error.. (TBD)
5.2-CMUSTPASSImplementations must use only statements associated with an authorization in the ACL RDF to determine access, except in the case of acl:agentGroup statements where the group listing document is dereferenced.
5.2-DMUSTPASSThe authorizations must be examined to see whether they grant the requested access to the controlled resource.
5.2-EMUSTPASSIf none of the authorizations grant the requested access then the request must be denied.
5.3-AMUSTPASSA 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.
5.3-BMUSTPASSA 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.
5.4-BMUSTFAILThe 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 specified LDP-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 headerTBD - Trellis does not support custom ACL locations.
5.5-BMUSTFAILIf an implementation chooses to reject requests concerning remote ACLs, it must respond with a 4xx range status code.TBD - Trellis does not support custom ACL locations.
5.5-CMUSTSKIPPEDIf an implementation chooses to reject requests concerning remote ACLs, it must advertise the restriction with a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.
5.6-BMUSTSKIPPEDIf an implementation chooses to reject requests concerning remote Group Listings, it must respond with a 4xx range status code.
5.6-CMUSTSKIPPEDIf an implementation chooses to reject requests concerning remote Group Listings, it must advertise the restriction with a rel="http://www.w3.org/ns/ldp#constrainedBy" link in the Link response header.
5.7.1-AMUSTPASSWhen a client has acl:Append but not acl:Write for an LDP-RS they MUST not DELETE, not PATCH that deletes triples, not PUT on the resource
5.7.1-BMUSTFAILWhen a client has acl:Append but not acl:Write for an LDP-RS and the implementation supports PUT to create they MUST allow the addition of a new child resource.Trellis aligns with SOLID on this specification.
5.7.2MUSTPASSWhen a client has acl:Append but not acl:Write for an LDPC they MUST allow a POST request.
5.7.3MUSTPASSWhen a client has acl:Append but not acl:Write for an LDP-NR they MUST deny all DELETE, POST, and PUT requests.
5.8-A-1MUSTFAILWhen an ACL includes an acl:accessToClass statement, it MUST give access to all resources with the specified type, whether that type is client-managed or server-managedTrellis (and SOLID) do not support acl:accessToClass.
5.8-A-2MUSTFAILWhen an ACL includes an acl:accessToClass statement, it MUST give access to all resources with the specified type, whether that type is client-managed or server-managedTrellis (and SOLID) do not support acl:accessToClass.
5.9-AMUSTPASSInheritance of ACLs in Fedora implementations is defined by the [SOLIDWEBAC]ACL Inheritance Algorithm and must be reckoned along the [LDP] containment relationships linking controlled resources
6.1MUSTPASSFor every resource whose state is changed as a result of an HTTP operation, there MUST be a corresponding notification made available describing that change.
6.2-AMUSTPASSThe notification serialization MUST conform to the [activitystreams-core] specification, and each event MUST contain the IRI of the resource and the event type.