More configurable mapping of format-sensitive path names across conversions

[wendellpiez]

User Story:

In Issue #398 we addressed the problem that processing dependencies in the OSCAL toolchain are represented by paths to files, which are format sensitive. We want an XML version of a profile to point to an XML catalog, while the JSON version points to the JSON version of the same catalog. This means a file path /my/xml/catalog.xml might need to become /my/json/catalog.json.

Expecting XML and JSON resources to be maintained in parallel, we can manage these relations -- and rewriting the values in conversion -- via configurable rules.

Addressing #398 we did this quick/dirty with a post-process. We need to make this more configurable, less opaque and tighter.

Goals:

Implement a mapping protocol to be produced for (in) the XML->JSON and JSON->XML conversions for any metaschema-based OSCAL model, which they can use to rewrite path names.

This can take the form of an external specification for any string conversions, expressed in XML so the converter-producer XSLT can read it and build templates from it. (Even a handwritten XSLT sub module could work if it's easy enough to rewrite.)

Only URI values (relative and/or absolute) as defined by a metaschema should be considered in scope. The mapping should have no effect in strings that are not typed as URIs.

While we are doing this, we can also address documentation needs.

Dependencies:

None presently.

Acceptance Criteria

• 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.
• Documentation on content conversions has been updated to describe the mappings, or an Issue has been created to reflect documentation requirements

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[david-waltermire]

Closing in favor of #623.