Add imported-from link rel to relevant SSP assemblies

[aj-stein-nist]

Committer Notes

{Please provide a brief description of what this PR accomplishes. Be sure to reference any issues addressed. If the PR is a work-in-progress submitted for early review, please include [WIP] at the beginning of the title or mark the PR as DRAFT.}

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers
  "?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you updated all OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the docs/content directory of your branch.
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?

[aj-stein-nist]

OK per the updated dependencies listing, I am gonna park this until #756 is implemented and circle back to this. Moving the linked issue in the TODO column.

[david-waltermire]

Please relocate the constraint for component/link/@rel to the system-component definition.

[aj-stein-nist]

Please relocate the constraint for component/link/@rel to the system-component definition.

So I pushed up a separate commit 497be0d and didn't squash it yet. I understand the request, but I am not sure how this will not lead to undesirable behavior. Can you explain to me when you have a chance?

If we move it here, does this not in fact allow this prop on any any component, not only a component instance in a SSP? Do we want abstracted component-definition(s) component(s) able to have this prop and potentially lead to confusion? Let me know what I am missing.

[david-waltermire]

LGTM. Thanks!

[aj-stein-nist]

The failed CI job was the link checker from cache errors with the W3C website docs, it worked after re-run. @david-waltermire-nist, per discussion during the weekly status meeting, this is ready for review.

[aj-stein-nist]

Please relocate the constraint for component/link/@rel to the system-component definition.

So I pushed up a separate commit 497be0d and didn't squash it yet. I understand the request, but I am not sure how this will not lead to undesirable behavior. Can you explain to me when you have a chance?

If we move it here, does this not in fact allow this prop on any any component, not only a component instance in a SSP? Do we want abstracted component-definition(s) component(s) able to have this prop and potentially lead to confusion? Let me know what I am missing.

Also just rebased down to one commit, as the feedback concern in #1403 (review) has been explained and addressed by Dave.

[david-waltermire]

@aj-stein-nist This PR needs to be rebased on the latest develop.

[aj-stein-nist]

@aj-stein-nist This PR needs to be rebased on the latest develop.

Rebased.

[aj-stein-nist]

Also TIL git commit --amend --signoff is needed to sign-off commits that are co-authored by team members. Now the PR commits are not so unverified.

[aj-stein-nist]

@david-waltermire-nist, I pointed this PR to a feature branch as instructed during the weekly sync for when we are ready to merge. Woops, this was meant for a totally different PR, disregard! 😆

[aj-stein-nist]

Rebased and waiting for pending feedback, but minor recommendation in #1403 (comment) was added before rebase. Should be good to go.

[david-waltermire]

LGTM. Thanks!