-
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
Registered extension name clarification #565
Comments
I agree that "registered" should mean "in the OCFL Extensions repository". I thus think that we should refine the definition of registered extension name as follows (italic = added):
But, if we do that, how do we still leave space for unregistered extensions? At present there is an underspecified notion of putting "a plain text document directly in the Storage Root". To my mind two things are missing:
Another option would be to remove from the spec the notion of trying to tie local extensions names to files in the storage root. It could always be added later. The current "Extension sub-directories SHOULD be named according to a registered extension name" allows wiggle room for directories not associated with registered extensions, and then we simply remove the text around
I didn't implement a test for |
@zimeon I do not validate I agree with what you said, and would take it a step further. I think that validators should warn on any extension they do not recognize/support. Some examples:
I do not think the presence of an unrecognized extension should ever be an error. [Edit] If extensions are validated as described here, then I do not think that it is necessary to formalize a naming convention for unregistered extensions. |
@zimeon : I agree that your refined definition for "Registered Extension Name" is helpful:
@pwinckles : I am not sure how your response gets us around the issue raised by @zimeon ("one might have to read every plain text document in the storage root and attempt to extract the name from the markdown?!?") without a further-specified naming convention. |
I was agreeing with this part:
To me, it doesn't seem worthwhile for validators to enforce the documentation of local extensions. And, if this is desirable, then the spec should define a naming format. |
Maybe it would help to clarify the goal of validating the extensions. My goal is simply to inform when the repository/object is using an extension that the client does not understand, which may be different from others' goals. If the primary goal is to ensure documentation, then why not warn on missing copies of the the OCFL and registered extensions specs too? |
2021-12-21 Editors agree refining definition of registered extension name, need to refine language about local extensions without trying to tie the "local extension name" to anything. Will not try to distinguish between a local extension and a registered extension that a validator doesn't know about -- either would generate a warning |
Will close this when corresponding Storage Root Extension clarification made in #583 |
closed with #607 |
The spec defines an registered extension name as follows:
It later says:
The later seems to indicate that all extension names, adopted or not, are "registered" so long as there is a plaintext document that describes them in the storage root.
If this is true, the following codes present an impossible problem to validators because there is no way to know what is or isn't an extension name:
E071
: ‘The value of theocfl_layout.json
extension key must be the registered extension name for the extension defining the arrangement under the storage root.’W013
: ‘In an OCFL Object, extension sub-directories SHOULD be named according to a registered extension name.’I had originally thought that "registered" extension names were only for extensions that were adopted into the extensions repository. In which case, validators would enforce those rules for the set of known extensions. And, I was going to file a ticket to say that I thought that
E071
would be more congruous if it was a warning rather than an error.So,
E071
to be a warning?The text was updated successfully, but these errors were encountered: