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

Consistency with Boolean fields or empty assemblies in OSCAL models #845

Closed
wendellpiez opened this issue Mar 10, 2021 · 1 comment · Fixed by #882
Closed

Consistency with Boolean fields or empty assemblies in OSCAL models #845

wendellpiez opened this issue Mar 10, 2021 · 1 comment · Fixed by #882
Assignees
Labels

Comments

@wendellpiez
Copy link
Contributor

wendellpiez commented Mar 10, 2021

Describe the bug

In the assessment-common metaschema, there are definitions for two assemblies include-all, one in control-objective-selection and one in assessment-subject. (These might be consolidated.) They are empty assemblies - no contents are permitted.

In the profile model, in contrast, there is the semantically similar (identical) element all, except this is a Boolean value.

So we have (SSP):

<assessment-subject uuid="...">
  <include-all/>
 ...
 </assessment-subject>

or

'assessment-subject': {
  'include-all': {}
}

Profile:

<import href="...">
  <include>
    <all>true</all>
  </include>
</import>
'import': {
  'href': '...',
  'include': {
    'all': true }
  }
}

These should be consistent since there is no difference in meaning between the two forms.

Who is the bug affecting?

Users who wish to learn one way to do it.

Expected behavior (i.e. solution)

If not make these both fields with Boolean values, then make them empty assemblies.

See: oscal_profile_metaschema.xml line 219, oscal_assessment-common_metaschema.xml lines 449, 499.

Other Comments

Our original model for the profile had the empty-element form, but we changed it to the Boolean form to match with developers' expectations (or our expectations of their expectations).

@wendellpiez
Copy link
Contributor Author

BTW this is a breaking change in data instances.

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

Successfully merging a pull request may close this issue.

2 participants