SSP Support Files Don't Follow Naming Convention

[brian-comply0]

Describe the bug

Prior to 1.0.0, the naming convention for the support files was discussed as intended to be:

• XML Schema: oscal_[model-name]_schema.xsd
• JSON Schema: oscal_[model-name]_schema.json
• XML to JSON Converter: oscal_[model-name]_xml-to-json.xls
• JSON to XML Converter: oscal_[model-name]_json-to-xml.xls

In this way, tools can programmatically fetch whatever support file they need for the model they were using by looking at the root element and replacing [model-name] with the root element. For example, a conversion routine can:

1. look at the model name and version
2. get the appropriate support file
3. use the support file to perform the conversion

All of the support files follow this convention except for the System Security Plan where the root name is system-security-plan, but the support files use ssp in the file name,

This one deviation from the naming convention impeeds tools from programatically selecting the correct support file based on the model they encounter.

Who is the bug affecting

Tool developers looking to programatically select the correct support file for a given OSCAL model and version.

What is affected by this bug

CI/CD

How do we replicate this issue

Simply look at the support file names for all published versions of OSCAL and compare them to the name of each model's root element. You will note that the convention is followed for six of the seven models

Expected behavior (i.e. solution)

Each of the SSP support files should be:

• oscal_system-security-plan_schema.xsd
• oscal_system-security-plan_schema.json
• oscal_system-security-plan_xml-to-json.xls
• oscal_system-security-plan_json-to-xml.xls

Other comments

For the work-around is to put an exception in any automated code specifically for the SSP model. If you decide to go back and fix this for all previous versions, I recommend leaving the current SSP support files with the incorrect names as well as duplicating them with the correct names. Otherwise, it further complicates any existing hard-coded file references as well as complicating any automated exception handling. Please at least fix this for any new versions of OSCAL.

Revisions

No response