Proof of concept of an ssp helper for jinja

[rahearn]

Types of changes

• Hot fix (emergency fix and release)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation (change which affects the documentation site)
• Breaking change (fix or feature that would cause existing functionality to change)
• Release (develop -> main)

Quality assurance (all should be covered).

• My code follows the code style of this project.
• Documentation for my change is up to date?
• My PR meets testing requirements.
• All new and existing tests passed.
• All commits are signed-off.

Summary

Opening this PR for feedback on approach. I was in need of these types of methods while writing a document-based SSP using trestle author jinja to pull the appropriate data out of my OSCAL SSP.

This obviously will need tests to be added before merging.

Key links:

• Sonar coverage

Before you merge

• Ensure it is a 'squash commit' if not a release.
• Ensure CI is currently passing
• Check sonar. If you are working for a fork a maintainer will reach out, if required.

[jpower432]

@rahearn I like the idea of an SSP interface for resuable logic around SSP data retrieval. Somewhat tangential, we do a lot of SSP processing in this package and I think if there was a SSP Interface, we could subsequently migrate some of that over.

[jpower432]

@rahearn Post community meeting, I wanted add some thoughts here and see if they aligned with what you got out of the meeting:

1. An SSPInterface would be generally helpful for data retrieval for the SSP object.
2. You need to be able to add this object to the Jinja lookup table without altering the code or a way to provide additional Python objects dynamically.

Does this sound right?

[rahearn]

Does this sound right?

Yes, it does. Where I was unclear after the meeting was what the timeline for that was, and whether this PR should be improved to either be a short-term gap filler or a start of that work, or if it should be closed and serve only as a proof-of-concept/early use case example. Do you have thoughts on that?

[jpower432]

Yes, it does. Where I was unclear after the meeting was what the timeline for that was, and whether this PR should be improved to either be a short-term gap filler or a start of that work, or if it should be closed and serve only as a proof-of-concept/early use case example. Do you have thoughts on that?

Good question. Since the timeline of the effort we disucssed yesterday is still undefined, I don't think we should make it a blocker for this work.

Maybe breaking up into two distinct PRs may help with this.

1. Adding the SSPInterface could serve as a short term solution and possibly used in the long term solution.
2. Address the Jinja lookup table requirement (maybe this would be a follow-on PR). This might have to use a plugin solution.

What do you think?

@butler54 @vikas-agarwal76 Please chime in if you disagree.