2019-09-04 Specification meeting

Bridge and Gateway not concerned with specifics of DDP 

Fiddly bit - OCFL expectation that versions will be numbers. Workaround is that there needs to be metadata in the OCFL. Version tag provided by the Gateway via the Bridge

Version numbers for OCFL become file layout details

Do all Bridge/DDP pairs support versioning? Configured at set-up time?

Gateway interprets all PUT requests at timestamp.

Versioning on or off for the entire flow. 

Supported: make me a version at this timestamp.

** Decision: Bridge supports versioning.

Version per filegroup. 

Gateway - whatever thing you’re versioning is the object

Use case- if I have a repo in Jan 2020 and I want to preserve objects including past versions from 2019. Should the repository be able to identify? 

** Question: Can you preserve a version in-between versions? Is this a use case that should be supported? Add to discussion for Monday. 

Audit parameter in query URL that gets you the version list. Too much data to cache? Best considered after figure out how Bridge handles versions. 

Is audit data available per version? Seen as an object. 

Bridge list deposited content call - where you see the list of versions. How does this look? Fine to pull all at once, cache, then query. 

Action items:

Tom - add versioning to the Gateway

Last week - write up the OCFL for DDP 

Tom and Bill - add handling for partial retrieval and specification of new versions.  

Same calls will need to be tweaked as mentioned in the last call. 

Write specs instead of having call.