Initial drafting of Storage Hierarchies section #180
Conversation
draft/spec/index.html
Outdated
| @@ -746,6 +754,38 @@ <h2>Root Structure</h2> | |||
|
|
|||
| <section id="root-hierarchies"> | |||
| <h2>Storage Hierarchies</h2> | |||
| <p> | |||
| <a>OCFL Object Root</a>s MUST be stored as direct children of a containing <a>OCFL Storage Root</a> or as the | |||
There was a problem hiding this comment.
I suggest "stored either as" to make it clearer that the MUST applies to either case. I'd be tempted to reverse the order as the directory hierarchy seems by far the more common use case
draft/spec/index.html
Outdated
| hierarchies, the following restrictions apply: | ||
| </p> | ||
| <ol> | ||
| <li>Storage hierarchies MUST NOT include files within interim directories</li> |
There was a problem hiding this comment.
I don't know what this bullet means
There was a problem hiding this comment.
Perhaps interim was intended to be intermediate but even then I'm not sure
There was a problem hiding this comment.
This is intended to mean that if you have a directory hierarchy, there can not be files (or OCFL Objects, for that matter) interspersed throughout that hierarchy.
draft/spec/index.html
Outdated
| <li>Storage hierarchies MUST NOT include files within interim directories</li> | ||
| <li>Storage hierarchies MUST be terminated by OCFL Object Roots</li> | ||
| <li>Storage hierarchies within the same OCFL Storage Root SHOULD share the same layout pattern</li> | ||
| <li>Storage hierarchies within the same OCFL Storage Root SHOULD NOT include mixed dispositions (zip, |
There was a problem hiding this comment.
not quite sure what the difference between "SHOULD share the same layout pattern" and "SHOULD NOT include mixed dispositions" is. The only addition in the second seems to be ZIP
There was a problem hiding this comment.
The difference in these bullets may be subtle, but testable.
Storage hierarchies within the same OCFL Storage Root SHOULD share the same layout pattern
This is intended to mean that if a directory hierarchy is used, the pattern is consistent.
Storage hierarchies within the same OCFL Storage Root SHOULD NOT include mixed dispositions
This is intended to mean that it is invalid to intermix directory hierarchies, top-level Objects and zips.
There was a problem hiding this comment.
OK, I see the point but did not understand that from the text. We should not use different terms "directory hierarchy" and "disposition" to mean pretty much the same thing. I propose:
- The storage hierarchy under an OCFL Storage Root SHOULD use just one layout pattern.
- The storage hierarchy under an OCFL Storage Root SHOULD consistently use either a directory hierarchy of OCFL objects, top-level OCFL objects, or OCFL Object ZIPs.
(and I think we also need a section describing in more detail what we mean by an OCFL Object ZIP... currently mentioned only in definition of OCFL Object Root... #181)
draft/spec/index.html
Outdated
| </li> | ||
| </ol> | ||
| <p> | ||
| Additionally, the directory name (or filename minus the extension for zip files) of an OCFL Object Root MUST |
There was a problem hiding this comment.
I do not think this should be a MUST, I would be OK with SHOULD. It only makes sense when combined with specification of a character encoding scheme, It might preclude long identifiers, and is certainly not necessary with various regular layouts. Even the PairTree spec admits both encapsulated and non-encapsulated forms
| </p> | ||
| <p> | ||
| A common practice is to use a unique identifier scheme to compose this storage hierarchy, typically arranged | ||
| according to some form of the [[PairTree]] specification. Irrespective of the pattern chosen for the storage | ||
| hierarchies, the following restrictions apply: | ||
| </p> | ||
| <ol> | ||
| <li>Storage hierarchies MUST NOT include files within interim directories</li> | ||
| <li>Storage hierarchies MUST NOT include files within intermediate directories</li> |
There was a problem hiding this comment.
Now that I understand it, this is a repeat of the MUST in lines 758,759 -- we should remove one
There was a problem hiding this comment.
Lines 758,759 say where OCFL Objects must be located. This line (767) says that no other files are allowed in the storage hierarchy.
| </p> | ||
| <p> | ||
| A common practice is to use a unique identifier scheme to compose this storage hierarchy, typically arranged | ||
| according to some form of the [[PairTree]] specification. Irrespective of the pattern chosen for the storage | ||
| hierarchies, the following restrictions apply: | ||
| </p> | ||
| <ol> | ||
| <li>Storage hierarchies MUST NOT include files within interim directories</li> | ||
| <li>Storage hierarchies MUST NOT include files within intermediate directories</li> | ||
| <li>Storage hierarchies MUST be terminated by OCFL Object Roots</li> |
There was a problem hiding this comment.
So an empty leaf directory in a storage hierarchy, or an empty storage root is illegal?
There was a problem hiding this comment.
empty leaf directory -> invalid
empty storage root -> potentially valid (Is it a "Storage hierarchy" with no OCFL Objects?)
Resolves: #123