At time of writing, we can patch at the "statement" level by specifying the deletion of control contents (parts, properties) and by augmenting controls (and subcontrols) with arbitrary contents (including new parts and properties to replace or supplement the old ones). But we do not have the capability to patch at finer levels of granularity -- for example, by removing or adding a single item to an 'objective' hierarchy (see //part[@class='objective'] in SP800-53).

Goals

Extend the addressing capabilities of alter elements in profiles so elements at arbitrary levels of granularity can be patched (contents edited/overwritten) in catalogs or (resolved) profiles being called. Demonstrate the capability in profile resolution (and display) logic.

Dependency

Examples demonstrating use cases in scope. Patching a single item inside an 'objective' hierarchy could be one. A pathological example might have to be created for very narrow patches such as a single list item inside a list.

NB that when deleting ol/li, the remaining ol/li in a list will be renumbered in (dynamic) display, so no "hole" ("missing list item") is visible. Entire statements (part elements) with labels, when removed, will however show jumps in numbering (where numbers are actually properties of the OSCAL statements, not display-time). Examples should illustrate this distinction.

Acceptance Criteria

• New examples(s) are added to the mini-testing library demonstrating these capabilities. They are commented and documented appropriately.
• Both removal/deletion of (granular) elements from controls, and augmentation/adding (at the point of address) are demonstrated.
• The solution including any syntax rules is documented for implementors. This includes discussion of when "holes will be visible" (as when statements with labels or visible names are removed) or not, as described above.

Notes

It is tempting to think about a little addressing language (I have notes), and somewhat daunting to think about its implementation. (Even if here we need to address within the scope of a single control/subcontrol, not arbitrarily in document or global scope.)

A consideration is that for deletion, selecting multiple elements (contents) at once is a feature, but for augmenting -- can a single patch affect multiple locations? Evidently, we need to be able to address specific elements, i.e. things like item[2] or item[2] description. A bare-bones version could permit addressing by ID (#id) or index (item[2]). XPath 1.0 could also offer an escape hatch (albeit with a new dependency).