[EPIC] Update XSLT profile resolver to current specification

[wendellpiez]

User Story:

The XSLT profile resolver (pipeline) provided in src/utils/util provides only a subset of the functionality described by the spec, enough to work for simpler baselines but not for complex cases using all features. Also, it already shows signs of 'dead code' from earlier releases that were hastily updated (see #1075).

With reference to unit testing showing inputs and expected outputs, this implementation should be completed, and/or its limitations fully documented with mitigation strategies.

This is a tracking issue for related tasks including both building and verifying unit tests, and development/testing.

Goals:

XSLT-generated report on current status of spec with provisional/draft unit tests in place. Checked items are tested.

• req-phase-order 5 Phases of Profile Processing It is strongly RECOMMENDED that implementations execute the following steps in the order that they are provided here (import, merge, modify). [test PENDING test design]
• req-uri-resolve 6.1.1 Import URI Resolution Tools MUST resolve URIs by following Section 5 of RFC3986, with the exception of URI Fragments (URIs that start with "#"). URI Fragments MUST instead be resolved as defined in . [test requirement-tests/req-include-all-asis.xml relative URI]
• req-uri-aquire 6.1.2 Import Resource Acquisition Tools MUST acquire resources at the resolved URI by following Section 5 of RFC3986, with the exception of URI Fragments (URIs that start with "#"). URI Fragments MUST instead be acquired as defined in . [test requirement-tests/req-import-by-resource.xml via internal reference to resource/rlink]
• req-uri-base 6.1.2 Import Resource Acquisition For the purposes of resolving URIs using the above specification, the Base URI MUST be considered to be the absolute URI of the containing profile. [test requirement-tests/req-include-all-asis.xml URI base corresponds to document URI]
• req-uri-error 6.1.2 Import Resource Acquisition In the case that acquiring a resource fails, the tool MUST cease processing and provide an error. In order to ensure profile resolution results in the same catalog regardless of which tool resolves it, all imports must successfully resolve. While this may cause inconvenience if resources are frequently not available, it ensures interoperability. [test requirement-tests/req-missing-resource.xml PENDING rebase over latest from galtm missing resource]
• req-internal 6.1.3 Internal References In the context of the Import Phase, internal references will only appear as a reference to a profile or catalog that is in the resources section of the source. When tools encounter such a reference, they MUST locate the object in resources with the matching UUID value, and resolve the resource. By OSCAL model requirements, a given resource can have zero to many rlink objects and zero to one base64 objects; however, it must have at least one of the two present. Tools can assume that any of these each resolves to the same underlying OSCAL object, although potentially in different serialization formats. For deterministic resolution of these backmatter OSCAL objects, tools need to adhere to the following requirements: [test requirement-tests/req-import-by-resource.xml ]
• req-internal-resolve1 6.1.3 Internal References Tools MAY use any of the rlink or base64 objects present in the resource. [test PENDING test design (support for either/both base64 and rlink)]
• req-internal-resolve2 6.1.3 Internal References Tools MAY verify that each above objects resolves to the same underlying OSCAL object. If there are OSCAL Model content differences between the resolved objects, the tool SHOULD provide a warning. [test PENDING test design (correspondence of base64 and rlink-nominated objects)]
• req-internal-resolve3 6.1.3 Internal References When a rlink is encountered and is to be resolved, it MUST be resolved by using a HTTP request to retrieve a byte stream. [test PENDING test design (retrieval)]
• req-internal-resolve4 6.1.3 Internal References When a base64 is encountered and is to be resolved, it MUST be considered a Byte Stream. [test PENDING test design (base64 integrity)]
• req-internal-resolve5 6.1.3 Internal References Regardless of its source, the Byte Stream MUST be decoded based on the algorithm defined in Section 4 RFC 4648. [test PENDING test design (base64 integrity)]
• req-internal-error 6.1.3 Internal References If the object fetched cannot be found or is not a valid OSCAL object, the tool MUST cease processing and provide an error. [test requirement-tests/req-missing-resource.xml PENDING rebase over latest from galtm] [test requirement-tests/req-broken-import.xml PENDING rebase over latest from galtm]
• req-circular-resolve 6.1.4 Resolving Imports of Profiles If the resource acquired is an OSCAL Profile, the tool MUST apply this specification to resolve it, then continue processing having imported the resulting catalog. [test requirement-tests/req-chained-all-asis.xml PENDING chained profiles]
• req-resolve-profile 6.1.4 Resolving Imports of Profiles When a profile imports a profile, the subordinate profile SHOULD be resolved first into a catalog using this specification, before it is imported. [test requirement-tests/req-chained-all-asis.xml PENDING chained profiles] [test requirement-tests/req-chained-deepA.xml PENDING [bug repair] chained profile merged with controls from its own source catalog]
• req-circular-error 6.1.4 Resolving Imports of Profiles If a processor encounters a circular import as described above (self-imports are inherently circular), the processor MUST cease processing and generate an error. [test requirement-tests/req-circular_import.xml PENDING circular import detection]
• rq-mulitple-imports 6.1.5 Multiple imports Note that this occurs even if the same catalog is imported multiple times: each distinct import collects controls into a separate selection [test requirement-tests/req-chained-deepA.xml PENDING chained profiles]
• rq-multiple-merge 6.1.5 Multiple imports The control inclusions are combined and collapsed in the next phase of processing [test requirement-tests/req-chained-deepA.xml PENDING chained profiles]
• req-include-all 6.2.1 include-all When an import provides the include-all directive, ALL controls and groups in the referenced document (including nested controls) MUST be included. [test requirement-tests/req-include-all-asis.xml ] [test requirement-tests/req-include-all-flat.xml ]
• req-include-by-id 6.2.2 include-controls plus with-id When an import provides the include-controls directive, with a with-id child, all controls in the referenced document whose id match one of the listed id values MUST be included. [test requirement-tests/req-include-by-id.xml ]
• req-include-by-match 6.2.3 include-controls plus matching When an import provides the include-controls directive, with a matching child, all controls in the referenced document whose id matches one of the listed pattern values (Glob matching) MUST be included. [test requirement-tests/req-include-by-match.xml ]
• req-include-by-match-empty 6.2.3 include-controls plus matching If a matching object is provided with no pattern, it MUST be treated as matching nothing. While not providing a pattern is technically valid, resolution tool implementers should be aware that it is generally undesirable, and warnings or notices to the user may be appropriate. [test requirement-tests/req-include-by-match-empty.xml ]
• req-with-child-controls-yes 6.2.4.1 with-child-controls A with-child-controls: yes directive on an include-controls indicates that all descendant controls of the included control MUST also be included. [test requirement-tests/req-include-by-id.xml ]
• req-with-child-controls-no 6.2.4.1 with-child-controls A with-child-controls: no directive on an include-controls indicates that ONLY the matching control is included, any descendant children MUST NOT be included. [test requirement-tests/req-with-child-controls-no.xml ]
• req-with-child-controls-none 6.2.4.1 with-child-controls If no with-child-controls is provided, the processor MUST consider the directive as being equivalent to one having with-child-controls:no. [test requirement-tests/req-with-child-controls-none.xml ]
• req-with-parent-controls-yes 6.2.4.2 with-parent-controls A with-parent-controls: yes directive on an include-controls indicates that all parent controls of the included control MUST also be included. [test requirement-tests/req-with-parent-controls-yes1.xml PR https://github.com/Profile resolver: Test merge phase, plus minor XSLT enhancements #1207] [test requirement-tests/req-with-parent-controls-yes2.xml PR https://github.com/Profile resolver: Test merge phase, plus minor XSLT enhancements #1207]
• req-with-parent-controls-no 6.2.4.2 with-parent-controls A with-parent-controls: no directive on an include-controls indicates that ONLY the matching control is included, any parent MUST NOT be included. [test requirement-tests/req-with-parent-controls-no1.xml PENDING PR https://github.com/Profile resolver: Test merge phase, plus minor XSLT enhancements #1207]
• req-with-parent-controls-none 6.2.4.2 with-parent-controls If no with-parent-controls is provided, the processor MUST consider the directive as being equivalent to one having with-parent-controls:yes. [test requirement-tests/req-with-parent-controls-none.xml Neither setting is given]
• req-exclude 6.2.5 exclude-controls Any control designated to be both included and excluded, MUST be excluded. This holds irrespective of the specificity of the selection for inclusion or exclusion. [test requirement-tests/req-include-exclude1.xml ] [test requirement-tests/req-include-exclude2.xml ] [test requirement-tests/req-include-exclude3.xml ]
• req-exclude-additional 6.2.5 exclude-controls When exclude-controls has at least one with-ids or matching directive, the processor MUST follow the same rules as defined in the relevant sections above for these directives, but exclude instead of include any controls. All optional features (with-child-controls, etc.) also apply to exclusion directives. [test requirement-tests/req-include-exclude4.xml ]
• req-redundant 6.2.6 Redundant Inclusions and Exclusions A given import may have any number of inclusion statements and any number of exclusion statements. Their effect is cumulative; any control that is included (or excluded) more than once MUST be considered to be included (or excluded) only once. In other words, a given control being included or excluded more than once has no effect. Exclusion still takes priority over inclusion (see above). [test requirement-tests/req-include-exclude4.xml ]
• req-loose-param 6.2.7 Handling Params All loose params from both imported documents and the profile source MUST be included. These params will be kept in the final output if the document contains any references to them, and discarded otherwise. See .
• req-merge-order 7 Merge Phase It is RECOMMENDED that tools apply the "combine" directive to the intermediate generated by the Import phase first, then apply the "structuring" directive. [test PENDING is this testable?]
• req-merge-combine 7.1 The "combine" Directive Note that "merge: combine" is deprecated, and MUST be considered undefined behavior when encountered. [test PENDING specification]
• req-merge-none 7.1.1 No Combine Directive If no merge directive is given in the profile, or if a merge is given without a combine, merge conflicts MUST be treated as if method: keep was given. [test requirement-tests/keep-everything-twice.xml ]
• req-merge-keep *7.1.2 method:keep * When a merge is indicated by method:keep, or when no merge directive is given, the keepcombination rule is used. Any control with the same distinctive ID MUST NOT not merged. (They are kept.)
• req-merge-keep-warning *7.1.2 method:keep * Processors SHOULD provide a warning under the merge:keep directive when duplicate controls are detected.
• req-merge-keep-error *7.1.2 method:keep * The processor MAY throw an error and cease processing (short-circuiting a certain future error) when duplicate controls are detected under the merge:keep directive.
• req-merge-use-first *7.1.3 method:use-first * When the "use-first"combination rule is applied, and controls that share a distinctive ID are found, the first control encountered MUST be kept, the rest MUST be discarded. "First" MUST be determined by a top-down, depth-first traversal of the source profile's import hierarchy.
• req-stucture 7.2 The "structuring" Directive Optionally, one of three "structuring" directives can be included as a child of merge: flat, as-isand custom. When one of these appears, it is the selected structuring directive. If more than one appears, processors MUST generate an error and cease processing.
• req-structure-none 7.2.1 No Structuring Directive If no merge directive is given in the profile, or if a merge is given without a structuring directive, structuring the output MUST be treated as if the structuring directive flat was given. For example, a profile with no merge directive: [test requirement-tests/req-include-all-flat.xml ]
• req-merge-flat 7.2.2 "flat" Profiles with the "flat" merge directive MUST be resolved as unstructured catalogs, with no grouping or nesting of controls.
• req-merge-flat-list 7.2.2 "flat" Unstructured catalog output MUST be produced by adhering to the following requirements:
• req-merge-flat-list-1 7.2.2 "flat" All included controls are output to the target as a flat list directly under "catalog".
• req-merge-flat-list-2 7.2.2 "flat" Any included "loose params" are output to the target as a flat list directly under "catalog".
• req-merge-flat-list-3 7.2.2 "flat" Any groups are discarded.
• id-structure-as-is-list *7.2.3 as-is * Processors MUST handle the as-is directive by adhering to the following requirements:
• id-structure-as-is-list-1 *7.2.3 as-is * All included controls are output to the target, keeping the structure of the groups and nested controls. Any group that holds an included control MUST appear in the output with all of its non-control children intact. If an included control has a parent control that was not included, that control's output location is "up-leveled", or made equal to the non-included parent. This applies recursively until the control is directly under either "catalog" or another included control.
• id-structure-as-is-list-2 *7.2.3 as-is * Any included "loose params" are output to the target as a flat list directly under "catalog".
• req-custom-group 7.2.4.1 Creating Custom Groups A groupobject given under custom MUST result in a group with the exact same content (excluding insert-controls) in the target catalog.
• req-custom-group-contents 7.2.4.1 Creating Custom Groups If the ID of the group matches the ID of a group that has been included during the import phase, all contents inside the group, including title, param, prop and part objects MUST be copied into the target, appearing in the same order as in the source.
• req-custom-select 7.2.4.2 Inserting Controls When processing the control selection of a custom element, the behavior defined in this section MUST be followed to generate the output.
• req-custom-select-ignore 7.2.4.2 Inserting Controls In the case that a control selection matches none of the included controls, it MUST be ignored.
• req-custom-select-warning 7.2.4.2 Inserting Controls In the case that a control selection matches none of the included controls, a warning SHOULD be provided.
• req-modify-set-param-warning 8.1 Setting Parameters If no such parameter is found, a warning SHOULD be issued.
• req-modify-set-param-id-ignore 8.1 Setting Parameters If no such parameter is found, processing MUST still continue.
• req-modify-set-param-objects1 8.1 Setting Parameters For the following objects inside the source: class, depends-on, label, usage, values, select; the object MUST be copied into the target from the source, first removing any existing objects with the same name.
• req-modify-set-param-objects2 8.1 Setting Parameters For the following objects inside the source: props, links, constraints, guidelines; the contents of the object MUST be added to the contents of the target object of the same name. If no such object exists in the target, it is created.
• req-modify-set-param-objects3 8.1 Setting Parameters For the following objects inside the source: prop, link; the object MUST be copied into the target from the source, first removing any existing objects with the same distinctive ID. ().
• req-modify-param-multi 8.1 Setting Parameters If more than one set-parameter directive is given for the same parameter, all MUST BE applied, in the sequence given in the profile.
• req-modify-alter-add-implicit 8.2.1.1 Implicit binding An add directive with no by-id child MUST be considered an implicit binding, and will apply to the control as a whole.
• req-modify-alter-add-implicit0contents 8.2.1.1 Implicit binding The contents of an implicitly bound add directive MUST be added to the control contents in the target, either after its title when position is starting, or at the end if its position is ending, or if no valid position is given.
• req-modify-alter-add-implicit-position 8.2.1.1 Implicit binding When an add directive is implicitly bound, the position values before and after MUST be treated like starting and ending, respectively.
• req-modify-alter-add-implicit-order 8.2.1.1 Implicit binding After processing an implicitly bound add directive, the control contents MUST be sorted to appear in the required order: a new prop appears after any prop already in the control, when position is ending, or not given, or before any prop in the control when position is starting.
• req-modify-alter-add-explicit 8.2.1.2 Explicit binding An add directive with a by-id child MUST be considered an explicit binding, and applies to only a single object inside the control.
• req-modify-alter-add-explicit-id 8.2.1.2 Explicit binding When an add directive is explicitly bound, the value of the by-id child MUST correspond to the value of an id on an object inside the control, and not the control itself.
• req-modify-alter-add-explicit-id-ignore 8.2.1.2 Explicit binding If by-id does not correspond to such a value, the add directive MUST be considered inoperative and ignored.
• req-modify-alter-add-explicit-id-warning 8.2.1.2 Explicit binding An inoperative add directive MAY result in a warning.
• req-modify-alter-add-explicit-inside 8.2.1.2 Explicit binding When position has a value of startingor ending, the contents of the source MUST be added inside the target, either at the start or end of its contents, respectively.
• req-modify-alter-add-explicit-outside 8.2.1.2 Explicit binding When position has a value of before or after, the contents of the source MUST be added outside the target, either directly before or after it, respectively.
• req-modify-alter-add-nested *8.2.1.3 Modifying controls inside controls * Profile resolution tools MUST be able to correctly handle add directives targetting nested controls. This includes directives that target a child control as well as directives that target a parent control and modify the child.
• req-modify-alter-remove-match 8.2.2 Removing contents from controls An object inside the control MUST be removed from the output if and only if it meets all of the criteria given by the child objects of the remove directive.
• req-modify-alter-remove-by-id 8.2.2 Removing contents from controls The remove directive criteria by-id MUST match an object if and only if its value is identical to the id value of that object.
• req-modify-alter-remove-name-ref 8.2.2 Removing contents from controls The remove directive criteria name-ref MUST match an object if and only if its value is identical to the value of that object's name child.
• req-modify-alter-remove-ns-ref 8.2.2 Removing contents from controls The remove directive criteria ns-ref MUST match an object if and only if its value is identical to the value of that object's ns child.
• req-modify-alter-remove-class-ref 8.2.2 Removing contents from controls The remove directive criteria class-ref MUST match an object if and only if its value is identical to the value of that object's class child.
• req-modify-alter-remove-item-name 8.2.2 Removing contents from controls The remove directive criteria item-name MUST match an object if and only if its value is identical to the value of that object's serialized name.
• req-modify-alter-remove-item-name-array 8.2.2 Removing contents from controls In serialization formats that use arrays of objects in the OSCAL model, an object's name MUST be referenced as singular form of its containing parent array.
• req-backmatter 9.1 Backmatter Resolution The output's backmatter MUST be generated by copying in each resource object from the backmatters of the imported catalogs/profiles in top-to-bottom order, then by copying in each resource object from the backmatter of the source profile itself. These objects MUST be processed in the order they are defined in each respective document.
• req-backmatter-dupe 9.1 Backmatter Resolution If a given resource has the same uuid as a resource that has already been added, the previous resource MUST be removed, and the more recent one added, unless superseded by other requirements.
• req-backmatter-keep 9.1 Backmatter Resolution A resource with a child prop of name:keep and value:always MUST NOT be replaced by the addition of another resource, unless the new resource also has a child prop of name:keep and value:always.
• req-backmatter-prune 9.1 Backmatter Resolution Tools MAY check for pruning conditions as resources are added as long as the final result is the same as if the pruning had taken place at the end of all resource addition.
• req-meta-uuid 9.2 Metadata Resolution The output catalog's metadata MUST have a unique top-level UUID (metadata:uuid). This UUID MAY be generated as seen fit by the tool, as long as it is reasonable to assume it is globally unique. It is RECOMMENDED that tools use a Version 4 UUID as specified in Section 4 of RFC 4122.
• req-meta-version 9.2 Metadata Resolution The value of metadata:version in the target MUST be set with a string that identifies the version of that document.
• req-meta-version-track 9.2 Metadata Resolution The metadata:version SHOULD be used to track updates to this specific output document.
• req-meta-oscal-version 9.2 Metadata Resolution The value of metadata:oscal-version in the target MUST be set with a string that identifies the version of OSCAL used by this tool to resolve the profile (ex. 1.0.0). This value MUST be determined by compiling the oscal-versions from each imported document and the source profile, and taking the most recent minor version. If this version is more recent than what the resolution tool is using, then the value of oscal-version MUST be the version that the tool used internally.
• req-meta-oscalversion-error 9.2 Metadata Resolution If any of the above OSCAL versions (imported document versions, source profile version, tool version) are of a different major version (the first digit differs), the tool SHOULD provide an error and cease processing.
• req-meta-last-modified 9.2 Metadata Resolution The value of metadata:last-modified in the target MUST be set with a valid timestamp representing the time the profile resolution completed.
• req-meta-source-profile 9.2 Metadata Resolution A child prop object with name:source-profile MUST be created. The value object of this prop SHOULD be set with a valid URI that points to the profile that resulted in this catalog.
• req-meta-source-profile-privacy 9.2 Metadata Resolution If there are privacy or security concerns, the value object of this prop MAY be set to anything, in which case the simple existence of the source-profile property indicates that this is a resolved profile.
• req-meta-resolution-tool 9.2 Metadata Resolution A child prop object with name:resolution-tool SHOULD be created. The value object of this prop in the target SHOULD be set with a string that represents the tool that was used to resolve this catalog.
• req-meta-keep 9.2 Metadata Resolution For any metadata:roles or metadata:parties that exist in the source catalogs, if they have a prop child with name:keep and value:always, they are to be copied as is into the output metadata.
• req-prune 9.3 Pruning and Ordering The processor SHOULD prune the resulting output catalog by removing unused objects.
• req-prune-keep 9.3 Pruning and Ordering Any object that has a child prop with a name of "keep" and a value of "always" MUST NOT be pruned.
• req-prune-include 9.3 Pruning and Ordering If an object was explicitly included in the , it MUST NOT be pruned.
• req-prune-custom 9.3 Pruning and Ordering If an object was referenced in a custom section of the source profile, it MUST NOT be pruned.
• req-prune-modify 9.3 Pruning and Ordering If an object was referenced in the modify section of the source profile, it MUST NOT be pruned. Any objects removed in that section are still removed.
• req-prune-ref 9.3 Pruning and Ordering If the object appears in a reference anywhere in the final result catalog, except in other objects that also meet all other pruning criteria, it MUST NOT be removed. A reference to a given object exists if #{distinctiveID} appears anywhere, where {distinctiveID} is the distinctive ID of the object .
• req-reorder 9.3 Pruning and Ordering Tools MUST reorder the output catalog into canonical order , except where this specification provides different ordering requirements.
• req-id-id 10.1 Distinct ID of Objects For the objects control, param, and group, distinctiveness MUST be determined by the value of the "id" child object.
• req-id-uuid 10.1 Distinct ID of Objects For the object resource, distinctiveness MUST be determined by the value of the "uuid" .
• req-multiformat 10.2 Dealing with Multiple Formats Profile Resolution tools SHOULD be able to handle source profiles, imported catalogs, and imported profiles that are serialized in XML, JSON, or YAML.
• req-multiformat-differ 10.2 Dealing with Multiple Formats A different serialization format of any given input MUST NOT result in a differing output catalog.
• req-output-xml 10.2.1 Requirements and Guidance for XML Output The final Catalog output, if using XML, MUST be valid as defined by the XML model documentation for the OSCAL Catalog. See the complete XML reference for model requirements.
• req-output-json 10.2.2 Requirements and Guidance for JSON Output The final Catalog output, if using JSON, MUST be valid as defined by the JSON model documentation for the OSCAL Catalog. See the complete JSON reference for model requirements.
• req-output-yaml 10.2.3 Requirements and Guidance for YAML Output The final Catalog output, if using YAML, MUST be valid as defined by the JSON model documentation for the OSCAL Catalog.
• req-order 10.2.4 Order of objects in serialization When the output format is XML, tools MUST use the OSCAL canonical order as described above. When using the YAML or JSON formats, order conveys no meaning, and is not considered important.
• Provide documentation of known limitations

Dependencies:

1. A full set of unit tests demonstrating profile resolution features

Acceptance Criteria

• A set of unit tests has been stood up that adequately reflects coverage for requirements in profile resolution (see: Profile Resolution Requirement Driven Unit Tests #1087)
• The XSLT profile resolver has been run on this set of tests, and either passed, or failures are sequestered and managed (e.g. documented as limitations)
• How to use the XSLT profile resolver, including current limitations, has been documented for users

Plus, as for all Issues:

• All OSCAL website and readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

[galtm]

@wendellpiez : #1101 has some overlap with this issue.

[david-waltermire]

@wendellpiez Can you enumerate what work needs to be done for this issue to be closed? Please edit the top-level description to include a checklist. Thanks!

[wendellpiez]

Work progresses steadily on the XSLT profile resolver thanks to @galtm - if anything the blocker for this Issue is the work now behind the WIP branch here: https://github.com/wendellpiez/OSCAL/tree/profile-resolution-update-v1d namely the end-to-end unit tests, with the coordinating glue (syntax/tools) to line them up with the specification requirements (as encoded).

This will be very helpful but 97 unit tests have not yet been written.

Assuming we have coverage of the specification addressed in some way (implicit in the framing of the Goals), actually showing that our current-best resolver actually does them should be a task but not an adventure. 🤞

[wendellpiez]

I just edited the description with three new bullets let me know what you think @david-waltermire-nist ?

[wendellpiez]

As requested by @david-waltermire-nist I rewrote the goals above - they might need work.

Update: @galtm continues to work on the XSLT profile resolver (now working the merge phase) while I am building out and framing unit tests. More to come.

[wendellpiez]

Discussed in sprint meeting 4/14 - we agreed I would move forward with end-to-end tests tied to the current specification, trying to make as much headway as possible, with a view to triaging all the requirements in the near term (next week or two). Indexing the spec to the tests as we work makes it easy to track coverage.

Given a concrete list of requirements with (some tests), we can define concretely the features that will and will not be provided by the profile resolver, which in turn helps us prioritize as we build out and stabilize the rest of the end-to-end tests.

[wendellpiez]

Progress report - this work continues and will proceed in the feature branch https://github.com/usnistgov/oscal/tree/feature-profile-resolution-unittesting

[wendellpiez]

As of pm June 15, 33 itemized requirements are being unit tested.

Another 32 items are marked as PENDING for various reasons, to be returned to.

41 items remain for examination in the first pass (will keep working on it).

A number of new issues have been identified, see https://github.com/usnistgov/OSCAL/issues?q=is%3Aopen+is%3Aissue+label%3A%22Profile+Resolution%22

Also see new discussion issues for various questions wanting clarification.

[aj-stein-nist]

As an epic predating #1688 board reorganization, I will want to label this as needs refinement for now until it can be broken down, rescoped, and or closed.