Profiles when resolved should show their provenance

[wendellpiez]

User Story:

A profile when resolved produces a catalog representing the baseline, selection or customization of the source catalog(s), as described by the profile. This "resolved profile" document has its own metadata - derived from the metadata of the source document - but it is not readily discernible that it (nominally a catalog) is actually a "resolved view" of a profile represented anywhere (such as the XML or JSON document from which it was produced).

The document metadata of a resolved profile should say that it is a resolved profile and link to its source documents, not only the ultimate catalog or upstream profile sources, but the source profile document.

In doing so it can refer to a resource in back-matter produced by profile resolution to specify and link to the nominal source, including both identifying information (its uuid and/or info from its metadata) and any available address(es) for its retrieval.

Goals:

• Update specs to define this behavior
• Update tools to conform to specs
• Take advantage of features of uuid properties on source documents to document provenance
• Document what happens in profile resolution to make it traceable
• Document any expectations or best practices especially relating to uuid assignments and traceability.

Dependencies:

No known external dependencies. Profile resolution must be stable.

Updating the tools will include updating any applicable unit tests to reflect new requirements in the outputs.

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• 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.

[david-waltermire]

@wendellpiez We need to design an approach and discuss this with the model review.

We should consider bumping this to OSCAL 1.1, unless this can be handled completely using link and prop.

[wendellpiez]

Agreed.

[wendellpiez]

Let's revisit with current work on #954 #1076 #1086. There is now language in the spec to address this requirement (albeit without the more cumbersome resource apparatus suggested here).

[aj-stein-nist]

This might be closable, @david-waltermire-nist will talk about this when we hop back into triage.

[david-waltermire]

This is addressed by prop[@name="source-profile"].