You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an OSCAL model developer, I need a succinct way to view, understand, and propose refinements to the model.
As a new OSCAL user, I need a succinct technical overview of the OSCAL models.
Goals
The goal is to create a feature-* branch to propose abstract information model content for OSCAL. OSCAL is defined using Metaschema which is based on text content of the models. An abstract IM is an alternative higher-level way to define, view and generate the same models, similar to the way the structure of web pages can be defined using bare-bones HTML and then customized for appearance using CSS.
As an example of how it might be used, this is a hypothetical proposal to update the Catalog model from a nested set of Controls and control groups to unified flat lists of controls and groups. The advantage of the abstract IM is that it allows the structure of Catalog to be seen and discussed at a higher level than at the XML document level.
Another example is a graph of the assessment-common types. The large set of types results in a large graph, but the abstract view may still be more approachable than the XML specification. This graph was generated from the abstract IM, which in turn was generated from the 1.1.2 release files.
The feature branch would be populated with proof-of-concept code to generate abstract IMs from OSCAL releases as they are developed. If this proves useful to the OSCAL community, it could be developed toward production-ready with documentation and test suites
Dependencies
None. OSCAL releases are the input to the IM generator; OSCAL content is input to the validation tests. Testing and schema robustness would be greatly enhanced by a larger collection of both good and bad (undesirable but not rejected) documents.
Acceptance Criteria
All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Revisions
No response
The text was updated successfully, but these errors were encountered:
@davaya - David, than you for creating the issue that describes your proposed Information Model representation of OSCAL. Looking forward to your proof of concept code.
The feature-information-model branch was created from develop branch.
User Story
As an OSCAL model developer, I need a succinct way to view, understand, and propose refinements to the model.
As a new OSCAL user, I need a succinct technical overview of the OSCAL models.
Goals
The goal is to create a feature-* branch to propose abstract information model content for OSCAL. OSCAL is defined using Metaschema which is based on text content of the models. An abstract IM is an alternative higher-level way to define, view and generate the same models, similar to the way the structure of web pages can be defined using bare-bones HTML and then customized for appearance using CSS.
As an example of how it might be used, this is a hypothetical proposal to update the Catalog model from a nested set of Controls and control groups to unified flat lists of controls and groups. The advantage of the abstract IM is that it allows the structure of Catalog to be seen and discussed at a higher level than at the XML document level.
Another example is a graph of the assessment-common types. The large set of types results in a large graph, but the abstract view may still be more approachable than the XML specification. This graph was generated from the abstract IM, which in turn was generated from the 1.1.2 release files.
The feature branch would be populated with proof-of-concept code to generate abstract IMs from OSCAL releases as they are developed. If this proves useful to the OSCAL community, it could be developed toward production-ready with documentation and test suites
Dependencies
None. OSCAL releases are the input to the IM generator; OSCAL content is input to the validation tests. Testing and schema robustness would be greatly enhanced by a larger collection of both good and bad (undesirable but not rejected) documents.
Acceptance Criteria
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Revisions
No response
The text was updated successfully, but these errors were encountered: