-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object storage layout disposition hint #138
Comments
I think we should allow this, but it should not be part of the OCFL specification. IOW, if the Pairtree spec provides a way of communicating the storage layout disposition, we should not prevent this but we should not invent one as part of our activities. |
I think we are really rather short of Use Cases to motivate decisions about storage layout, from a quick look I see only Rebuildability as having direct influence. Should we try to flesh out the use cases a bit? |
Have attempted to write up the use case I have for this: OCFL/Use-Cases#31 |
Here is the kind of spec I have in mind:
|
👎 I think this raises more questions than it solves. |
There are comments/examples in the Implementation Notes. At the moment, there is no statement about the form of hints other than that they are nice-to-have. I do suggest maybe having a documentation OCFL Object referenced in the storage root. That can then hold as much hint material in easily readable form as you want, along with exposing it to preservation checks. |
I propose we close this issue, as it as been handled in the implementation notes and #214 |
Should we allow for a Object storage layout disposition hint, along the lines of '1=pairtree_1.0', etc
The text was updated successfully, but these errors were encountered: