Misleading XML Schema documentation for control-implementation implemented-requirement #1194
Comments
|
The relevant objects in the component definition need to be clarified that the control details are suggestions for possible implementations in the component definition. In the SSP, the relevant objects document what was actually implemented. This needs to be clarified in the relevant metaschemas. |
david-waltermire
added a commit
to david-waltermire/OSCAL
that referenced
this issue
May 4, 2022
…inition as only a suggestion of how to implement. Resolves usnistgov#1194.
9 tasks
9 tasks
Rene2mt
pushed a commit
to Rene2mt/OSCAL
that referenced
this issue
May 17, 2022
…inition as only a suggestion of how to implement. Resolves usnistgov#1194. (usnistgov#1232)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
This was recently discussed and an issue was requested.
See the 1.0.2 complete XML schema line 2672.
The prose statement implies semantic equivalency of
<implemented-requirement>in both<system-security-plan>and<component-definition>. The element name assists with such an interpretation.Who is the bug affecting?
Developers who rely on XML Schema documentation.
What is affected by this bug?
Despite the element name equality, the semantic import is supposedly different.
When does this occur?
Durably (unless the documentation were to be changed).
Expected behavior (i.e. solution)
Identically named elements in different OSCAL documents have identical semantic import.
The text was updated successfully, but these errors were encountered: