introduce is_required field for all output_types

[nickreich]

The idea here is that we want to separate out whether or not a specific output_type is required for a submission from the specification of which output_type_ids are required or optional.

Noting that we already have implemented this for sample output_type.

[annakrystalli]

In the process of implementing this it occured to me that it could be much less invasive and easier to propagate throughout the hubverse if, instead of introducing the is_required property as a property of output_type_id, it could be a property at the the output_type level. e.g.

{
    "output_type": {
        "quantile": {
            "output_type_id": {
                "required": [0.25, 0.5, 0.75]
            },
            "value": {
                "type": "integer",
                "minimum": 0
            },
            "is_required": true
        }
    }
}

This has both practical and conceptual benefits in my view:

• Practical: It would make implementing the change across packages much easier because we are not mixing the values expected in the output type id column with an additional logical property that needs to be ignored.
• Conceptual: Whether an output type is required or not is an output type level property not an output type id level property. As such it feel conceptually more accurate to nest it at the output type level. This becomes clear when trying to write output_type_id object descriptions in the schema. If we include the is_required property in the output_type_id object, it again feels like we're mixing two distinct things together.

[elray1]

This makes sense to me. Maybe we should also change the location of this setting for the sample output type, for consistency.

[nickreich]

I agree as well. Seems like a good solution.

[annakrystalli]

@elray1 yes I thought that too. Will implement for samples too.

[zkamvar]

Question: do we have a practical way to do an integration test of the schemas before approval?

That is: do we currently have a system for us to run tests on hub with our packages using the new schema or is it all manual?

[annakrystalli]

Question: do we have a practical way to do an integration test of the schemas before approval?

Not really. We test that they are correct json and that jsonvalidate can parse them correctly and therefore use them to validate config.

I think the practical element is the difficulty here.

The features of interest of new versions are the basis for new functionality/ associated introduction of back-compatibility which requires new features and updating or creating new example data and tests in our packages. This happens within our packages and the direction is necessarily the creation of a new schema PR first and then packages are updated and tested against the new schema version PR before it is merged.

Having said that, I have opened the following issue for suggestions on how to improve our tests so thoughts on the above welcome there: #89