Time/Place

Attendees

(plus) (facilitator)
(star) (notetaker)

Agenda

  1. Open PRs  ...ready to go?
  2. Authorization issues to be decided upon
    1. Deadline for "completing" webac section:
      • all 5 sections covered by end of Aug
    1. "Sprint" on AuthZ until Jul 26th
  3. Deletion-related issues to be decided upon
    1. Recursive delete is not required
    2. Require use of headers to indicate capability
  4. At least one other implementation of the specification
    1. Cavendish discussion
  5. Option for implementation of test suite - contractors
    1. Contractors have been contacted and are interested... even if Python
    2. Better error output from tests: What was request, what was response, and what requirement was tested
    3. Provide LDP spec to contractors
    4. Provide Fedora API documentation to contractors
    5. Initial test: Resource Management - GET, HEAD, POST
    6. Initial tests should be limited to things that Fedora impl already does

Minutes

  1. Open PRs
    1. Esmé will create a new PR incorporating agreed-upon language from https://github.com/fcrepo/fcrepo-specification/pull/137
  2. Andrew created issues for the differences between the SOLID guidelines and the current implementation.
    1. Will create a delta doc 
    2. Re: #163: Simeon will create a PR to add language about always having a Link rel="acl" and using the default
    3. Re: #166: Do we need WebIDs, or are any URIs enough?
      1. Any URI should be enough, dereferencing etc. are not required for WebAC to work
    4. Re: #168: Referencing ACLs/groups outside of the repository — we should add a non-normative note about this
      1. Maybe add an item to the security considerations section too?
    5. Re: #164: There is a note about webac:defaultForNew being renamed to webac:default, but not when
      1. Simeon will ask if/when this will be changed so we can know which we should use
    6. Andrew will start moving them forward — provide feedback on the issues before Friday
  3. Deletion
    1. We have agreed that recursive deletion isn't required, and headers should be used to indicate capability
    2. Sticking point is what does containment, and atomicity (should be handled in atomic operations spec)
    3. Ben will check with Hydra stakeholders about expectations for recursive deletion
    4. Danny will open a PR to add non-normative note about atomicity not being guaranteed, and that the Depth header should be respected
  4. Multiple implementations
    1. We should work towards cultivating other implementations, including aligning the Modeshape impl. with the spec, Cavendish, etc.
  5. Test suite
    1. Need to be able to run with different implementations in different languages, environments, etc.
      1. Don't want to conflict with Java projects' dependencies
      2. Don't want to require non-Java projects to setup Maven just to run the test suite
    2. Andrew will contact the contractors about scoping and specifying work

Action Items

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.