Versions Compared

Old Version 2

changes.mady.by.user Danny Bernstein

Saved on

compared with

New Version Current

changes.mady.by.user Jared Whiklo

Saved on

Key

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

...

  1. Danny Bernstein
  2. Peter Eichman 
  3. Bethany Seeger 
  4. Jared Whiklo (star)
  5. Andrew Woods
  6. Kevin Ford
  7. Ben Pennell 
  8. Aaron Birkland  
  9. Mohamed Mohideen Abdul Rasheed
  10. David Wilcox 

Agenda

  1. Announcements

  2. Sprint 2 ProgresProgress

  3. Open questions: 

    1. Shall we stop rejecting PUT requests that only contain SMTs in addition to your chosen triples? (Jared Whiklo )?
      1. Current situation:  to replace non-server managed triples in RDF you must
        1. GET with `-H"Prefer: return=representation; omit=\"http://fedora.info/definitions/v4/repository#ServerManaged\""`  and PUT with  `-H"Prefer: handling=lenient; received=minimal"`
        2. Does the above conflict with https://fcrepo.github.io/fcrepo-specification/#http-put-ldprs
        3. Also seems to make complicated what should be a simple thing for the user to accomplish.
      2. Documentation of SMTs:
        1. https://docs.google.com/document/d/1xmuzYwMn0r3p5Dgch7GX3DACftL-3nr5ImSqt_KpUbk/edit?usp=sharing
      3. Related questions:
        1. What are our SMTs? What is the impact of allowing them to be modified?
        2. What is an acceptable workflow for changing interaction models? Does the presence of a matching rdf:type in the RDF matter?
        3. What is an acceptable workflow for updating the properties of a resource?
        4. What is an acceptable workflow for restoring a version? (either from a memento or from a local export)
    2. Should GET ONLY return SMTs when specifically requested?
      1. Essentially, reverse the current behavior by requiring an "include" header instead of an "omit"
      2. Should PreferContainment header be considered a subset of SMTs i.e. should they be suppressed on omit SMT? (Not relevant if we going to reverse the current behavior?)
    3. Shall we make all resources versionable by default? 
        1. Follow-on question:  Should it be possible to make resources non-versionable?  In other words, are we saying, everything is versionable, period?
        2. Implications:  
          1. Remove DELETE LDPCv
          2. Remove "Enable Versioning" from HTML UI

  4. <your agenda item here>

  5. Please squash a bug!

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13122
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  6. Tickets resolved this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13111
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  7. Tickets created this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13029
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Minutes

  1. Next sprint starts next week!

  2. Lots of work happened during the sprint - many CTS tests filled in.  Nice job!
  3. Sprint 2 Strategy and Goals
    1. Goal: get to the Release Candidate
      1. There are a number of tickets there that we know we want to address.  Priority on those first. 
      2. Setup Release Testing work - pages, testing that the process still works and address any issues seen.  
      3. Documentation
      4. Jared suggests focusing on the maybe 5 tickets that are bugs, leaving new features for later.  
        1. Suggestion of looking at all tickets to prioritize them. 
      5. Someone can look at fcrepo-camel-toolbox and java client to get an idea of what needs to be done there.  
    2. Secondary Goal: tool set.  Priority would be to update camel-toolbox and java client first, vagrant last (as it depends on the other things and may not be much more work to update). 
      1. Ben P. suggests documenting the changes that are needed to the fcrepo tool set: fcrepo-camel-tool box, java client. 

  4. Open questions: 

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2730
      1. Tests are old tests, but they only break on this branch based on new stuff Jared is doing in his PR. 
      2. Mac 10.10.5 doesn't show this error.   (10.10.3 = Yosemite)
      3. 4 tests failing in FedoraLDPIT tests.  Same 4 tests failing.  Something to do with setting text HTML in header - to return the web page. Maybe something to do with how Grizzy is working; may be a timing issue. 
      4. Peter E. Do we think this is a network/stack/socket communication problem?  Any leads on what's causing it? He's seen some weirdness in their batch loading clients in the network HTTP/TCP stack that weren't working in Mac OS High Sierra, but worked on Sierra. High Sierra may have broken some networking issues.   Danny B. suggests leaving it since it may be a Mac issue - but many of us use Mac OS's to build; we'd have to ignore those tests.  Can we do a conditional ignore on Mac OSX's?
      5. Jared suggests we try to look at this more.  In the test, in Velocity the SessionFactory and http servlet request is injected, using context...?.  Maybe something he's written there is not the best way to do this.  Info he's trying to get is that it needs to know if it is a memento and if it's versionable.   Maybe there's an easier/better way to get that data?
      6. One proposal – have someone look at it now
      7. Or make a ticket, put a conditional ignore on the tests, put some manual tests for this in the release plan, and keep moving forward, addressing this later. 
      8. Ben Pennell may take a short look at it. (He has a High Sierra mac)
    2. Data URIs in the constrainedBy link header
      1. Default response on malformed RDF is a Data URI in the constrained By link. We are not using data uris anywhere else.  You can't just easily read the response and see what's happening there.  
      2. No objection to changing that.  Danny B. will create a PR.
    3. Prefer headers on Mementos:  https://github.com/fcrepo4/fcrepo4/pull/1420
      1. Question1:  Should the original resource return  <> a ldp:Container and <> a ldp:RDFSource  when omitting server managed triples (currently these are being omitted in OriginalResource but not the Memento)
        1. The thought is that this is a new bug - that the original resource should return those two triples.  Danny B will create this ticket. 
        2. Danny B will create a documentation ticket for what the SMT's actually are. 
      2. Question2: How should fedora respond to requests to Prefer omit
        1. In theory they should be the same - that what you see with the original based on the representation request, should look the same in the memento. 
        2. Proposal 1:  Mementos should behave like the original resource
            1. We'd like to go with this. 
    4. All AuthZ tests assume literal agent values
      1. Danny believes we have some way to handle this. You can specify the baseURI for agents?  The actual logic is backwards from expected. It retains the comparison between the username from current user and the agent value - is still a string comparison of just the user name.  The BaseURI user webac uri prefix, its not being added to the principal from the container, but it is being stripped coming from the WebAC. Logically you end up comparing things in the correct sort of way. 
      2. Maybe the fix is to make sure that the values going into the ACL's are URIs.  Any of the agents that are being tested by the CTS should probably be URI's.  Then when running against fedora, we'd have to specify the agent base URI to start up the server with. 
      3. Need to start collecting a recipe of how to configure your fedora to run the CTS on it.   (external content setup, webac agent setup, etc)
      4. CTS is assuming HTTP basic auth; leaving out server certs, OAuth, etc.. What should we support?  What does the Fedora API have to say about how it get a user name from the request? Is anything specified for that?
      5. WebID passed in the header? WebID TLS - auth using WebID – Solid spec mentions this by name. https://github.com/solid/solid-spec#webid-tls
      6. Maybe create an issue for this and address it during the upcoming sprint. 
      7. Solid spec mention WebID and WebID TLS, but don't seem to be musts. 
      8. Question of what are we assuming about WebID based on what Solid requires?
      9. Zimeon raised a point about users and names and we should check in with him
      10. All of CTS assumes basic auth but some systems may not be using basic auth. Would be hard to cover testing all auth systems.  We could work with folks implementing the spec and see what they are using. 
      11. Aaron Birkland mentioned CLAW and JWT's - solution was to have the system hand off a http client off to APIX, which does all the JWT stuff.  We could add an authentication interface for the CTS  in order to delegate authentication to the implementation. The tradeoff – Fedora implementors will  have to implement the interface.   However, this approach might be more practical than trying to support specific systems folks are using. 

Future Agenda Topics: 

  1. Future Agenda Topics: 


3. Open questions.

  • Properly suppressing Server Managed Triples, how do we deal with ldp:contains.
    • Meta-conversation about what are Fedora's SMTs and the workflow.
    • Updating a properties of a resource requires a special header to GET and to PUT. Do we reverse the behaviour and get back the non-SMTs by default. But you are lacking some of the useful triples (lastModified).
    • We expect that READ is a more common action than write.
    • ldp:contains should be a SMTs, which makes (for Jared) suppressing SMTs by default a less enjoyable process.
    • Having Fedora ignore SMTs included in a PUT does not seem to be a breaking change and could be done post-5.0.0 release.
    • Should be able to update SMTs if you need to.
  • How do you restore a Memento?
    • Currently need to GET a Memento, set Fedora to relaxed mode, then restart and PUT with Prefer: handling=lenient; received=minimal
    • Need to have relaxed mode on a per-request
    • Is this an authZ question? Should only certain people be able to restore versions?
    • What is the result of a restore? Do you get all the previous triples whether they are SMTs or not? That seems to be the consensus.
    • Consensus is to use a new Prefer header to allow per request overwriting the entire resource including any SMTs.
    • Will restoring a Memento result in restoring an older ACL? Consensus is NO, the Memento is separate. The link to the ACL is a static link added by the server and because the resource is not removed/re-added the current ACL will remain.
    • Discussion to occur in Slack
  • Changing interaction models?
    • Currently there is no way to change between interaction models.
    • Currently you can add types in the ldp: namespace, this should not be allowed.
  • Make all resources versionable by default?
    • Yes. Danny to create a JIRA to enable versioning. Also create JIRA to tag code that is used for enabling versioning for future review.
  • Reviewing list of SMTs that Ben created
    • Is the list full and complete?
    • What is the expected behaviour in interacting with SMTs.
    • "Anything that is created by the server" as the rule for SMTs?
    • Anything created by the server, where if they did not exist the interaction would be indetermined.
    • Any triples added to the resource as they are being generated on request. `ldp:contains` and some fixity ones. Also with RDF serialization.
    • Also make sure that on the testing side we ensure the correct behaviour of SMTs.
  • Amherst College's acrepo apache camel services: https://gitlab.amherst.edu/acdc/repository-extension-services
  • Reviving OAI