Configurable default directory for loading constraint files in batch

[aj-stein-gsa]

User Story:

As a developer of that creates or imports data in the OSCAL format, I would like the ability to set an environment variable (and/or possibly a configuration file, for environment flexibility) to allow loading oscal-cli validate ... without explicitly using -c constraint1.xml and -c constraint2.xml and -c constraintN.xml repetitively.

I am willing to work on this one myself. 😄

Goals:

• Simplify and minimize the artifice needed to run commonplace commands
• Make modular rebuilding of tools not require more explicit configuration and processing of arguments
• Logging that mentions constraints that are processed to make developer/engineer awareness explicit without directly providing commonplace constraints in a trusted location

Dependencies:

N/A

Acceptance Criteria

• All 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.

[david-waltermire]

Here is some brainstorming around how this could be handled.

1. One way to approach this would be to define a metachema model for an "environment" that could incorporate multiple external constraints.

   Something like:

   <environment>
     <external-constraint>path-or-url-for-constraint</external-constraint>
     <external-constraint>path-or-url-for-constraint</external-constraint>
   </environment>

   We could then have a --environment <resource> argument.

2. Alternatively, external constraints already support imports, which can be used to reference other constraint dependencies. This could allow a single constraint set to be referenced using -c <importing resource>. This alternative approach would not require any additional support than what is already implements.

[aj-stein-gsa]

These are not bad ideas, I would also support them. I really was proposing an environment variable because that can be prepared in a container image configuration without any additional runtime arguments. Overlaying directories with symlinks does not work well and we want to give users a mount to their user-controlled directory and make it more seamless. 1 and 2 are close, but the ergonomics still require you to have additional arguments and handling at runtime that require extra effort and crafting files with absolute paths (when relative paths aren't very effective with directories that are not close to each other).

I hope that makes sense, I would love to discuss more.