Keep the existing parameter value when a set-parameter supplies none

[arpitjain099]

Committer Notes

handleSetParameter assigns param.setValues(new LinkedList<>(setParameter.getValues())) unconditionally, so a set-parameter that adjusts only a label, usage, constraint or guideline replaces the parameter's inherited values with an empty list. Every other field in that method goes through ModifyPhaseUtils.merge or mergeItem, and both return the original when the profile side is null or empty.

The reference resolver keeps the original. In oscal-profile-resolve-modify.xsl the param template selects (value, select, $settings/(value,select))[last()], which falls back to the catalog's own value when the set-parameter carries none. As it stands, a profile that only renames a parameter drops that parameter's value from the resolved catalog, and the value then goes missing from anything generated downstream.

The added test resolves a one-control catalog whose parameter has a value, through a profile whose set-parameter sets only a label, and checks both the new label and the retained value. Without the source change it fails with expected: <[catalog value]> but was: <[]>. The existing modify-adds example does not catch this because its parameter has no value to lose.

ProfileResolutionTests passes locally on JDK 11: 21 run, 0 failures, with the one pre-existing skip.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• 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?

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 all website and readme documentation affected by the changes you made?