WIP: Extensions

[ahankinson]

A "commit early, commit often" take on the wording for the extensions directory. Still todo:

• Add general 'extensions' description (top-level section?) to which we can refer as a general description of extensions and their mechanics.
• Review requirements for extensions in Object root
• Add language about storing plain text descriptions of the extension in the object root

Add any missing things you see to the list.

[awoods]

So far so good... pending finalization of the name of the extensions directory.

[rosy1280]

Some questions and clarification because its a work in progress!

[rosy1280]

not understood

that's a little unclear. we should be a bit more specific. i'm assuming you mean by a validator that understands the spec and/or that can validate whatever the extension asks it to validate.

[ahankinson]

I took the language from the existing §4.4, "An OCFL validator must ignore any files in the storage root it does not understand."

We also have (in §3.4): "Optional fixity algorithms that are not supported by a client must be ignored by that client."

So would something like

Extension directories that are not supported by a client MUST be ignored by that client

make sense? Should we narrow it down specifically to validation, or just leave it open generally to "clients"?

[zimeon]

I think it should be "clients" and agree with last wording suggestion

[neilsjefferies]

I think stick with validators - this is the spec for objects at rest. We can discuss clients in the Implementation Notes (Client Behaviour's section) - ignoring extentions when writing is dangerous.

[rosy1280]

This makes it sound like their is a difference between extensions that appear in the storage root and the object root. I thought we had agreed that Extensions would be stored at the root and then used in the objects -- but you might not use all extensions listed in the storage root.

[ahankinson]

There are extensions, like the “layout” functionality, that will be root-only. (The demo from @birkland) In this case it does not affect the contents of objects, but only the paths to them.

[zimeon]

Change title to "Storage Root Extensions"

[zimeon]

... which still leave the question of where descriptions of object extensions go

[ahankinson]

Descriptions of object extensions also go in the storage root as a plain text file, on the theory that it is a single place that can describe the structure of some or all objects in that storage root.

[neilsjefferies]

Agree with @ahankinson

[zimeon]

Capital D in directory to match section title style

[zimeon]

• Here we do not make it illegal to have files in the extension directory, I think that is the intention
• I would also say the sub-directories SHOULD be named according to a registered name rather then MUST

[ahankinson]

Point 2: SHOULD would leave open the possibility of multiple things implementing the same extension but with different local names. This would make it difficult for clients to understand that it can operate on that content.

The alternative would be to use a NamAsTe file to declare an extension's identity in the root directory of that extension, e.g., extensions/versioning/0=mutable_head-1.0, which would allow us to name things differently. But this was an unpopular suggestion on the editorial call.

[neilsjefferies]

Aren't the directories under extensions a namespace that references OCFL extentions - in that case, there should only be a single instance of any one type.

[ahankinson]

My concern is that by making it a SHOULD we leave open the possibility that people name their directories in extensions in a way that diverges from the name that is registered by the extension.

[neilsjefferies]

@ahankinson I'm agreeing with you!

[zimeon]

I'd go for SHOULD instead of MUST again, I'd also put any such language next to the sentence about the name

[ahankinson]

SHOULD would leave open the possibility of registered and unregistered namespace collisions -- two extensions with the same name but different functions. By making it a MUST we reduce this possibility.

[awoods]

Superseded by: #428