include-all flag in OSCAL 1.0.0 unusual for most parser designs.

[butler54]

User story

As a json (schema) user include-all has a counter intuitive structure, in that in theory there are many valid structures that could be achieved such as

"includes":{"include-all":{}}"

would be valid, however, technically any value would be valid e.g.

"includes":{"include-all": True}"

"includes":{"include-all":{"bananas":"rule"}}"

This produces uncertainty in parser models which interpret profiles in JSON and YAML.

Recommended Solution

I think a good solution from a json POV would be to make include-all an optional boolean. This is a little fraught as technically {"include-all": False} would be backwards incompatible, however we could limit this behaviour by convention / design (which as a schema attribute would be a bit messy, however, could be formalized).

[david-waltermire]

The JSON schema fragment for this property is currently:

"oscal-profile-oscal-profile:include-all" :  {
        "title" : "Insert All",
        "description" : "Insert all controls from the imported catalog or profile resources identified in the import directive.",
        "$id" : "#assembly_oscal-profile_include-all",
        "type" : "object",
        "additionalProperties" : false
}

This means that the property can only ever be an empty object, because of the "additionalProperties" : false. This means that the following variants will not be allowed by a validating parser.

"includes":{"include-all": True}"

"includes":{"include-all":{"bananas":"rule"}}"

Are there concerns about having an empty object?

[david-waltermire]

We discussed this on the 6/25/2021 model review. There seems to be an emerging consensus that changing this to a boolean field with a required true value would be ideal; however, there was also some consensus that this change should be made in a 2.0 release. We discussed writing an issue to collect these types of changes for 2.0.