Time/Place

Attendees

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

Agenda

  1. What are the issues that need resolution prior to June 20th?
  2. External content
    1. Issues: https://github.com/fcrepo/fcrepo-specification/issues?q=is%3Aissue+is%3Aopen+label%3Aexternal-content
    2. Needs more editorial review, also pending response to existing comments: https://github.com/fcrepo/fcrepo-specification/pull/121
  3. What to do with: PUT/POST with Content-Location:
    1. https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/domain/ContentLocation.java
    2. https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/domain/ContentLocationMessageBodyReader.java
    3. https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraLdp.java#L327
    4. Response to list inquiry of usage of Content-Location ingest feature and possible migration to external/body?cache?
  4. Fixity section: https://github.com/fcrepo/fcrepo-specification/issues/100
  5. Clarify HEAD behavior https://github.com/fcrepo/fcrepo-specification/issues/103
  6. Clarify InboundReferences https://github.com/fcrepo/fcrepo-specification/issues/119
  7. Branding as Core Specification https://github.com/fcrepo/fcrepo-specification/issues/122
  8. Publication of Fedora ontology: https://github.com/fcrepo/fcrepo-specification/issues/108

Minutes

  1. We'd like to have the initial draft ready in about 2 weeks, what needs to be resolved before then?
    1. Andrew: There are some issues that are more conversational
    2. Esme: External content seems like a big one, there are several other issues that have been identified as workable
    3. Simeon: I'm having some doubts about the scope and how
    4. Ben: With the issues listed as action items, I think I could start implementing the outstanding functionality in Cavendish
      1. It seems like having things ready for initial implementation to further practical evaluation
    5. Simeon: There's a big gap between the spec and the Modeshape impl — what does that mean for e.g., Hydra and Islandora, etc.?
    6. Danny: Not fully implemented yet, but share the concern — the main thing is versioning, where we want to reconcile Drupal and Fedora versions
      1. Core CRUD is the main thing, and it's there
    7. Esme: Hydra uses a subset of the Modeshape impl functionality, and that subset is in the spec
    8. Andrew: The spec covers most of what is in the Modeshape impl, at least in functionality, even if the behavior is somewhat different
      1. Resolving the action items would put us in a good place for community feedback
  2. External content
    1. Esme: the PR looks good — just some technical questions and not substantive ones
    2. Expires issue: the mailing list thread seems resolved
      1. Ben: a side issue to the Content-Location issue
      2. Esme: not a thing we're specifying, but a good thing to note
    3. Andrew will make a PR to resolve the technical issues
  3. PUT/POST with Content-Location
    1. Andrew sent a message to the mailing list, and there have only been a couple of responses and there were no objections to potentially using a different mechanism
    2. Simeon: so we can close the issue
  4. Fixity
    1. Ben: The issue is that the fixity recommendations are all in information sections
    2. Andrew: So we'd need to update 5.1 to remove the reference to the removed fixity method
      1. And 5.2 would to be normative and refer to the 3.x sections that include Want-Digest
    3. Ben: I'm not sure we need to make 5.2 normative just because it refers to normative sections — there's no new testable behavior here
    4. Andrew: There is some new text and it should be in a normative section
    5. Ben: Since the spec is targeted at implementers, and we should make it as easy to read without jumping around
    6. Simeon: Should we move the section out of the list of requirements?
    7. Esme: I think that addresses Aaron's concern — it is moved out of the list of requirements because it's not normative, but remains as an informative section, since it's an important concept for Fedora
    8. Andrew and Danny: OK with that
  5. DELETE/Depth
    1. Andrew: This seems like a good starting point to me, but not sure what e.g, Depth: 5 means
    2. Esme: I agree: Depth: 0 and Depth: infinity are the ones that make sense for the Modeshape impl, and I'm happy to let other impl. find reasonable values for their impl.
    3. Danny: I would like to include something about emitting messages for async failures
    4. Simeon: This may be a rabbit-hole, should move to a separate ticket
    5. Danny: I want to include some language around failures
    6. Esme: I agree — we should definitely expect impl with immediately-consistent backends to report errors, async backends can fall back on messaging
  6. Clarifying HEAD headers
    1. We can be more explicit here, but should not need to require all Content headers
    2. Simeon will address this next week
  7. Branding
    1. Andrew: Important to get the branding question right
    2. Esme: Spec is narrower than the Modeshape impl, but don't want to imply that an impl. of the spec isn't useful
    3. Simeon: Want to make sure that a thing that is "a Fedora" is a useful thing
    4. Danny: We haven't done a very good job of specifying if the impls. aren't useful
    5. Andrew: We should look carefully at the spec and identify any places where we can tighten the spec to make sure an implementation
    6. Danny: "Core" to me still means something useful
    7. Andrew: The spec should be the minimal amount to call your impl. "a Fedora", and we should improve the spec if we don't think that's true

Previous Action Items

New Action Items

  • Andrew: Move Fixity section to the end and remove reference from Section 1
  • Esmé: Update Fixity section to include persistence fixity language
  • Danny: will move 111 forward, and create a separate ticket for async failures
  • No labels

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