Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Fedora 6.0.0-alpha build has the following results when the Fedora API TestSuite is run against it.

Req LevelNum PassNum FailNum Skip% Pass
MUST1427695%
SHOULD385188%
MAY2311896%
Total203132594%

For comparison here is the results of Fedora 5.1.1 are

Req LevelNum PassNum FailNum Skip% Pass
MUST1463698%
SHOULD4301100%
MAY30012100%
Total21931999%


Currently failing tests are:

  • 3.1.3-0: Implementations must allow the ldp:insertedContentRelation property to be set by default to an implementation defined value.
  • 3.1.3-P: Implementations SHOULD allow the ldp:insertedContentRelation property to be set by default to ldp:MemberSubject.
  • 3.10.2-D: A 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.2.1-B: In addition to the requirements of [LDP], an implementation ... may support the value http://www.w3.org/ns/oa#PreferContainedDescriptions for the Prefer header when making GET requests on LDPC resources.
  • 3.6.1-A: Any 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. (This is a failure of the test suite)
  • 4.1.1-A-1: If no LDPRm is appropriate to the Accept-Datetime value, implementations should return a 406 (Unacceptable).
  • 4.1.2-B: Must support PUT for updating existing LDPRvs
  • 4.2.6: LDPRm resources must support DELETE if DELETE is advertised in OPTIONS (https://github.com/fcrepo/fcrepo/pull/1790)
  • 4.3.3.1-E: If an LDPCv supports POST, a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body.
  • 4.3.3.1-F: If an LDPCv supports POST, a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the datetime given in the Memento-Datetime request header.
  • 6.1: For 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-A: The notification serialization MUST conform to the [activitystreams-core] specification, and each event MUST contain the IRI of the resource and the event type.
  • 6.2-B: Wherever possible, data SHOULD be expressed using the [activitystreams-vocabulary].

Upgrading to the Alpha

...

...