Update component and inventory prop type names

[aj-stein-gsa]

Committer Notes

Closes #2086 and #2092.

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?
• Have you updated the OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the OSCAL-Pages and OSCAL_Reference repositories.

[aj-stein-gsa]

@iMichaela will you have a chance to review this PR? We are planning a tentative release in the middle of March. These issues with the constraints in the core models are harder to work around than others for which I just added updates. If these cannot be reviewed, merged, and published into a release model, we can only workaround some of the issues. If not, that is fine, but FedRAMP leadership will have to consider alternatives to NIST-maintained models for that release.

Thanks in advance for your help and cooperation.

[aj-stein-gsa]

If these cannot be reviewed, merged, and published into a release model, we can only workaround some of the issues. If not, that is fine, but FedRAMP leadership will have to consider alternatives to NIST-maintained models for that release.

Thanks in advance for your help and cooperation.

Hello, @iMichaela, these proposed changes are to meaningfully align conflicting requirements in the internal models and FedRAMP use of core values. We will need to have duplicate and confusing use of certain props with FedRAMP namespaces to work around some of them, but others are not easy to workaround. If these proposed changes cannot be reviewed, with feedback to change or accept them as-is, I would like to know next steps towards the end of 7 March 2025 (not the completed decision, but what your plan and intent here is the maintainer of this project).

If not, we will have to consider alternative solutions, potentially forks of the models. Let us know.

[aj-stein-gsa]

@iMichaela any update on these changes, particularly #2111 (comment)? At this juncture, we may have to consider the publication of alternate models in a fork to finalize an upcoming release otherwise.

[iMichaela]

@iMichaela any update on these changes, particularly #2111 (comment)? At this juncture, we may have to consider the publication of alternate models in a fork to finalize an upcoming release otherwise.

Welcome back. I can prioritize this PR. Coming back to the @id comment - don't you think it should preserve the rule and require to be updated? Is there a good reason not to do so?

[aj-stein-gsa]

Welcome back.

Hi, @iMichaela, I've been here the whole time. 😄

I can prioritize this PR. Coming back to the @id comment - don't you think it should preserve the rule and require to be updated? Is there a good reason not to do so?

I did not have a good idea for an alternate changed name for the @id. I would have changed it in the interim if I had a good idea, that was the theme of #2111 (comment). Let me know and we can work to resolve this. I am hoping to propose a minor release with just these fixes, separate of the other related issues, after review is complete.

[aj-stein-gsa]

@iMichaela I proposed a new ID because I have not heard back with a proposal, so I just made one in #2111 (comment). Can you let us know because I will have to potentially push back a release schedule or consider forking or disabling internal constraints and ignore a good portion of the core models to not have conflicting data quality checks between core OSCAL and FedRAMP requirements that should have been aligned prior. Let me know if you need further details to advance a review.

[iMichaela]

@iMichaela I proposed a new ID because I have not heard back with a proposal, so I just made one in #2111 (comment). Can you let us know because I will have to potentially push back a release schedule or consider forking or disabling internal constraints and ignore a good portion of the core models to not have conflicting data quality checks between core OSCAL and FedRAMP requirements that should have been aligned prior. Let me know if you need further details to advance a review.

@aj-stein-gsa - I have something to finish now and will work on PRs later today and continue tomorrow afternoon. What is your schedule? Let's try to work toward your schedule.

[aj-stein-gsa]

@aj-stein-gsa - I have something to finish now and will work on PRs later today and continue tomorrow afternoon. What is your schedule? Let's try to work toward your schedule.

@iMichaela I was hoping we could opt for a minor 1.1.4 release in anticipation of a subsequent FedRAMP release some time tomorrow for such a change. Is that feasible? This is why I opened the PR last month.

[iMichaela]

@aj-stein-gsa - I have something to finish now and will work on PRs later today and continue tomorrow afternoon. What is your schedule? Let's try to work toward your schedule.

@iMichaela I was hoping we could opt for a minor 1.1.4 release in anticipation of a subsequent FedRAMP release some time tomorrow for such a change. Is that feasible? This is why I opened the PR last month.

@aj-stein-gsa -- Let's do it because I want to fix the bug I found while working on #2107. I know it is super important for FedRAMP.

[aj-stein-gsa]

@aj-stein-gsa -- Let's do it because I want to fix the bug I found while working on #2107. I know it is super important for FedRAMP.

I appreciate it. Barring alternative feedback, I committed the constraint ID with my proposal because you and no one else provided one. Let me know what else I can do.