Storage layouts defined by multiple extensions

[pwinckles]

It's possible, perhaps likely, that storage layouts will be defined using multiple extensions. For example, one extension might define an ID transformation such as removing a shared prefix from all object IDs, and another extension might define how to map the output of the transformation to an object root directory within the storage root. However, ocfl_layout.json only provides space for a single extension to be defined.

I can think of a couple solutions.

1. The spec could change to allow multiple extensions to be defined in ocfl_layout.json.
2. An extension could be created that does nothing other than chain other extensions together, feeding the output of one extension in to the next.

I currently think the later is a better approach, as an extension chaining extension can afford to be more descriptive on how a series of extensions interact than the OCFL spec can. In this case, the ocfl_layout.json would reference the extension chaining extension, which is parameterized for the definition of any number of extensions that are applied in sequence to map an OCFL object ID to an object root directory.

So, all of that to say, I don't think there's any action needed here, but I'm still creating this ticket because I was asked to on the community call.

[awoods]

Based on discussion during the 2020-09-01 Editors Meeting, option (2) above was preferred... in part due to the fact that option (1) would represent a spec breaking change.
Additionally, two suggestions were surfaced:

• It would be helpful to have some text in this repo giving guidance on how to create a chaining extension
• It would be helpful to include at least two examples in the OCFL spec with respect to ocfl_layout.json
  • One that is minimal
  • One that references a chaining extension

[awoods]

This should now be resolved with the use of an "Initial extension" at the storage root.
Closing.