Incorrect Links in Leveraging SSP and Component Definition

[rgauss]

Describe the bug

1. The source values in the example component definition reference a relative catalog and profile that contain /content in the path, which is no longer correct. The /content segment of the path should be removed.
2. The leveraged-authorizations in the example leveraging SSP references a relative link that no longer exists. It is likely intended to point to oscal_leveraged-example_ssp.<format> (and the rel value should probably indicate the correct format).

Who is the bug affecting?

Anyone working with the leveraging SSP and component definition examples.

What is affected by this bug?

The examples are incorrect and developers building tooling around them must compensate.

When does this occur?

Always

How do we replicate the issue?

N/A

Expected behavior (i.e. solution)

Links should be resolvable and correct.

Other Comments

[rgauss]

It looks like the component definition profile mentioned above will need to point to a different repo and filename as a result of recent commits.

[ohsh6o]

I had missed this during my PR and did not realize the sample components used the FedRAMP baselines in situ when drafting #70. @david-waltermire-nist, let me know. Since source can be a uri reference in JSON and uri-reference in XML should I just update the URL in a follow up PR?

Something like "source": "https://github.com/GSA/fedramp-automation/blob/master/baselines/json/FedRAMP_HIGH-baseline_profile.json" instead of the relative path?

[ohsh6o]

Talked to Dave, PR forthcoming.

[ohsh6o]

@rgauss, howdy, can you tell me if I got them all? The pipeline will generate the fixes from src/examples/xml so sometimes it will seem odd that I am fixing in a different respective format. Let me know if I got it right from eyeballing. I decided to fix not only the FedRAMP relevant things. :-)

[rgauss]

@ohsh6o, looks good from what I'm eyeballing as well, though I think we'll still have the issue of JSON SSP representation pointing to XML references, similar to #59.

[ohsh6o]

In which SSP? The only SSP I had looked at was that impacted by this issue, and it has an import-profile directive and no a back-matter/resource declaration. That example SSP in JSON form does not even have back matter statements either when put through the pipeline, and the import-profile directive is properly fixed.

Am I missing something in the PRed files or you want me to look at #59 at the same time?

[rgauss]

@ohsh6o, in the leveraging SSP, the leveraged-authorizations href and rel in the JSON representation point to the XML representation.

[iMichaela]

@ohsh6o and @rgauss - the XML reference in the JSON file is caused by the way the JSON content is generated automatically from the XML ones. There is an issue pointing to this fact and we will address it but it might be after 1.0.0 is released

[ohsh6o]

@ohsh6o, in the leveraging SSP, the leveraged-authorizations href and rel in the JSON representation point to the XML representation.

Sorry I thought you were being literal about placement in back-matter, apologies. Follow-up comment is applicable to Michaela's comment as well.

@ohsh6o and @rgauss - the XML reference in the JSON file is caused by the way the JSON content is generated automatically from the XML ones. There is an issue pointing to this fact and we will address it but it might be after 1.0.0 is released

Thanks for clarifying @iMichaela, I asked Dave to clarify on #59 on that very issue because I asked how to help with particular issue and how it matters here. @rgauss , I am sure you saw that update as well. It might be possible for me to help. I just wanted to clarify that here and now after conversation with Dave because it seems best to keep #74 scoped and not muck around with a significant pipeline enhancement here. :-)

Given that limited scope, I think #74 is ready for review. Sorry, Ray!

[rgauss]

@ohsh6o, sorry, I wasn't very clear in comments above. I was not expecting the XML references to be fixed as part of this issue, I was just mentioning it since those types of references were changed with the PR.

Thanks for your work on this!

[david-waltermire]

Merged PR #74, which addresses this issue.