-
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
Are Storage Roots optional? #620
Comments
@kieranjol we've talked about this but are currently split on whether or not we should clear this up sooner or later because of potential impact on 2.0. i know that's a non-answer but i wanted you to know we aren't ignoring you. |
Thank you so much for the reply! I’m glad that it’s being discussed! |
We discussed this on the editors' call today. The intention of the text in section 4.3 Storage hierarchies, a sub-section of 4. OCFL Storage Root and thus in the context of an OCFL Storage Root is:
There are certainly also uses of OCFL Objects that might happen outside of an OCFL Storage Root. For example, one might transfer and OCFL Object to or from a repository, one might assemble an OCFL Object outside of a Storage Root and then move it in, and I'm sure other cases too. Perhaps a clearer wording would be:
|
May need to tighten up language to make clear that OCFL objects are independently validatable. No substantive changes required though. |
Hi,
I'm reading through 1.1 and it's wonderful! Am I correct in thinking that a Storage Root is optional but highly recommended if you want to achieve the goal of rebuild-ability?
It seems that the key section is
4.3 Storage hierarchies
, and the lineThis makes me think that a valid OCFL object can exist without a Storage Root as long as it's the 'terminal resource'? I'd never heard the term 'terminal resource' before, but I'm guessing that it just means that the OCFL object is the final set of files/folders at the end of a hierarchy?
If storage roots are optional, should this be stated as an explicit
SHOULD
somewhere in the document?Best,
Kieran O'Leary
National Library of Ireland
The text was updated successfully, but these errors were encountered: