Skip to content
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

Workflow RO-Crate: clarify spec on workflow types #46

Open
simleo opened this issue Jan 26, 2023 · 3 comments
Open

Workflow RO-Crate: clarify spec on workflow types #46

simleo opened this issue Jan 26, 2023 · 3 comments

Comments

@simleo
Copy link
Contributor

simleo commented Jan 26, 2023

The current spec says:

The Crate MUST contain a data entity of type ["File", "SoftwareSourceCode", "ComputationalWorkflow"] as the Main Workflow.

This could be interpreted as saying that the types must be exactly ["File", "SoftwareSourceCode", "ComputationalWorkflow"], while WorkflowHub actually allows for more types to appear on the list. This is required by the Provenance Run Crate profile (which adds HowTo), so I propose we change the spec as follows:

The Crate MUST contain a Main Workflow data entity whose types MUST include File, SoftwareSourceCode and ComputationalWorkflow.

@fbacall
Copy link
Contributor

fbacall commented Mar 21, 2023

I missed this. I think this is a good idea.

I'm wondering what the best-practice way of changing this is now we have the versioned spec. Do you think it would be a breaking change to implementers? I guess possibly, if they are looking for the exact 3 terms to identify something as a main workflow...

@simleo
Copy link
Contributor Author

simleo commented Mar 21, 2023

if they are looking for the exact 3 terms

Yes, it's potentially breaking in case anyone is doing such a strict check, however unlikely. So the profile's version should change to 2.0.

In any event, it's very important that WorkflowHub keeps allowing the extra types as it does now, even with the current spec, so that Provenance Run Crates can be uploaded to the registry.

@stain
Copy link
Member

stain commented Mar 24, 2023

I would say it should bump to version 1.1, not 2.0, as anyone following 1.0 would still be in compliance even if we are now laxer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants