Document and update extension relationships

[zimeon]

Fixes #92 and #93

[zimeon]

Easiest way to review is to look at the pages rendered in the github ui for the extension-rels branch: https://github.com/OCFL/extensions/tree/extension-rels

[neilsjefferies]

This shouldn't be V1.0 any more.

[awoods]

Thanks, @zimeon . Two minor comments.

[zimeon]

@neilsjefferies - I think the editors need to discuss what the version of the extensions spec (ie. the readme https://github.com/OCFL/extensions) means. We have a number (1.0) in that readme/spec and on all extensions but we don't say anything about what sort of change could be expected if we move from 1.0 to 1.1 or 2.0, the implications for extensions that declare a particular extensions spec number, or even how we preserve "old" extensions specification versions.

I'm not convinced that we need to change the extension specification number for this change -- the validity of the current set of extensions is not changed and only the headers have been updated to improve/clarify linking between extensions. However, maybe working out what a change implies would help clarify.

[awoods]

@neilsjefferies - I think the editors need to discuss what the version of the extensions spec (ie. the readme https://github.com/OCFL/extensions) means. We have a number (1.0) in that readme/spec and on all extensions but we don't say anything about what sort of change could be expected if we move from 1.0 to 1.1 or 2.0, the implications for extensions that declare a particular extensions spec number, or even how we preserve "old" extensions specification versions.

I'm not convinced that we need to change the extension specification number for this change -- the validity of the current set of extensions is not changed and only the headers have been updated to improve/clarify linking between extensions. However, maybe working out what a change implies would help clarify.

I agree that we should clarify the meaning of changes to the extensions spec version number. Unless we decide on changing that number with every commit (unlikely), we should safely be able to move this PR forward in the meantime.