Cross-format capability in Profile Resolution

[wendellpiez]

User Story

Developers of Profile Resolvers and indeed their users face a choice: whether to support profile resolution across formats for which OSCAL is defined, or only within one or a subset of formats supported by OSCAL. I.e. a JSON-only profile resolver vs a profile resolver that can manage both JSON and XML inputs, discriminately or indiscriminately.

We wish to promote the development of both single-format and cross-format resolvers, while we recognize the latter to be a significant impediment for many developers and architectures. XML is literally the last thing many Javascript/JSON devs would like to be thinking about, for example.

Moreover, a 'cross-format' resolver does not necessarily mean a resolver handles all formats - just that it handles more than one.

Bottom line is that any resolver must be labeled and well defined wrt constraints on its inputs (and outputs). An "XML-only Profile Resolver" vs "JSON-only" vs "XML-JSON-YAML-capable" etc.

The Profile Resolution spec needs to define both kinds of processors and indicate how to label them. Also it would be great to specify fallback behavior for processors dealing with unsupported formats, e.g. if your JSON-only Profile Resolver is provided with XML inputs.

Goals

• Amend Profile Specification as necessary to define requirements and expectations for cross-format capabilities, both reading and writing, for Profile Resolvers consuming different forms of OSCAL - namely, that Resolvers are expected to document their limitations, etc.
• Follow this up with documentation -- or Issues leading to documentation -- of the capabilities of any Profile Resolvers we support

Dependencies

This work should probably be folded along with other Issues touching on the Profile Resolution spec, into #1087 and #1076. There is significant work in progress in a branch tracked there, which should be incorporated along with changes to the Specification.

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.

[sunstonesecure-robert]

just drawing on a system like Kubernetes which supports json, yaml and protobuf in the API server and etcd storage typically a content type indicator would be passed in (as a http header to the api server; as a cli flag to the config for the storage). so having some sort of "marking" of what is supported and what is expected seems reasonable.