In and for the OSCAL ecosystem, several NIST repositories include code bases and data sets factored out for use and maintenance. Many of these may wish to use software components maintained in others. In other words, there is a network, hopefully a unidirectional tree-shaped network, of dependencies and potential dependencies among OSCAL repositories.
For example, the OSCAL repository depends on the metaschema repository for schemas defining its metaschema instances, and on one or more Metaschema implementations for CI/CD operations, which may or may not be maintained together, etc.
Goal of this issue is to propose an overall architecture for submodule use among OSCAL repositories, suitable for maintenance and reuse, with a map or guide of how to migrate to it.
This may also entail refactoring Github repositories. For example, the XSLT utilities maintained in this repository (a "hub" repository for NIST tools and potential holding place, but not long-term home) should be spun out. Similarly, the Metaschema XSLT-M4 implementation could be spun out into its own repository independently of Metaschema.
Note that the plan could entail phases or longer-term staging: it doesn't have to be a simple solution, just the right steps in the right direction.
Work items:
[ ] Develop a plan with next steps
[ ] Available at an accessible location (paste or post link to this Issue)
[ ] Produce any follow-on Issues as needed (with appropriate links)
In and for the OSCAL ecosystem, several NIST repositories include code bases and data sets factored out for use and maintenance. Many of these may wish to use software components maintained in others. In other words, there is a network, hopefully a unidirectional tree-shaped network, of dependencies and potential dependencies among OSCAL repositories.
For example, the OSCAL repository depends on the metaschema repository for schemas defining its metaschema instances, and on one or more Metaschema implementations for CI/CD operations, which may or may not be maintained together, etc.
Goal of this issue is to propose an overall architecture for submodule use among OSCAL repositories, suitable for maintenance and reuse, with a map or guide of how to migrate to it.
This may also entail refactoring Github repositories. For example, the XSLT utilities maintained in this repository (a "hub" repository for NIST tools and potential holding place, but not long-term home) should be spun out. Similarly, the Metaschema XSLT-M4 implementation could be spun out into its own repository independently of Metaschema.
Note that the plan could entail phases or longer-term staging: it doesn't have to be a simple solution, just the right steps in the right direction.
Work items:
Potential split-out repositories
This site would continue to serve as hub for documents and demonstrations.