fix(generate): proposed transition of generation annotation to props

[brandtkeller]

Description

Proposing the transition of the generation to a control-implementation props such that it can be discoverable and easily updated.

Also introduces the framework flag as used in #327 for purposes of establishing the framework for a control implementation early.

The previous implementation placed the annotation in the component remarks. Problem is that this generation command is primarily creating and updating control implementations, and as such a single component may have 1 -> M control implementations which means a single component may have many generate commands for reproducibility.

Placing the annotation at the control-implementation layer feels more appropriate to scope and intent.

Related Issue

Fixes #572

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Schema Updates applied
• Contributor Guide Steps followed

[meganwolf0]

Looks like the remarks doesn't include the --framework tag when it gets generated (nor does it update on successive generations) - but looks like the new generation prop does. Do we need to keep remarks anymore?

Also, to maintain consistency, should we add a generation.md to the namespaces docs?

[brandtkeller]

Looks like the remarks doesn't include the --framework tag when it gets generated (nor does it update on successive generations) - but looks like the new generation prop does. Do we need to keep remarks anymore?

Also, to maintain consistency, should we add a generation.md to the namespaces docs?

Will look into the first item and great call on the additional docs.

[brandtkeller]

When I execute ./bin/lula generate component -c https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json -r ac-1,ac-3,ac-3.2,ac-4 -o oscal-component.yaml --remarks assessment-objective --framework il4 I see the following props:

props:
            - name: generation
              ns: https://docs.lula.dev/ns
              value: lula generate component --catalog-source https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json --component 'Component Title' --requirements ac-1,ac-3,ac-3.2,ac-4 --remarks assessment-objective --framework il4
            - name: framework
              ns: https://docs.lula.dev/ns
              value: il4

[meganwolf0]

When I execute ./bin/lula generate component -c https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json -r ac-1,ac-3,ac-3.2,ac-4 -o oscal-component.yaml --remarks assessment-objective --framework il4 I see the following props

yep those props look good and what I saw as well! I meant the remarks section that's in the control-implementation - that doesn't get updated and also feels redundant now

[brandtkeller]

When I execute ./bin/lula generate component -c https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json -r ac-1,ac-3,ac-3.2,ac-4 -o oscal-component.yaml --remarks assessment-objective --framework il4 I see the following props

yep those props look good and what I saw as well! I meant the remarks section that's in the control-implementation - that doesn't get updated and also feels redundant now

Ah! great point - we do a decent job at retaining information while merging - and so a previously generated file with still contain the generation annotation in the remarks is what you are getting at?

This is tricky - given how early the functionality is it feels like an edge case.

[meganwolf0]

Ok had to sanity check what I was even saying - yeah I think I had a previously generated component and that's why the remarks were there - starting fresh I don't have remarks. Sorry, disregard this! Agreed it's a weird edge case that's most likely not going to be an issue

[CloudBeard]

Works on my machine.

Outside of the fix I noticed if I ran

bin/lula generate component --catalog-source https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/yaml/NIST_SP-800-53_rev5_catalog.yaml --component 'Component Title' --requirements ac-1,ac-3,ac-3.2,ac-4 --remarks assessment-objective --framework il4

and

bin/lula generate component --catalog-source https://raw.githubusercontent.com/usnistgov/oscal-content/master/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json --component 'Component Title' --requirements ac-1,ac-3,ac-3.2,ac-4 --remarks assessment-objective --framework il4

I get the two implemented-requirements but they are technically the same just used a different source format yaml/json. I don't see anything wrong with with this but maybe something extra later on to figure out.

[brandtkeller]

I get the two implemented-requirements but they are technically the same just used a different source format yaml/json. I don't see anything wrong with with this but maybe something extra later on to figure out.

Two implemented-requirements or two control-implementations (that each have the 4 implemented-requirements)?

[CloudBeard]

I get the two implemented-requirements but they are technically the same just used a different source format yaml/json. I don't see anything wrong with with this but maybe something extra later on to figure out.

Two implemented-requirements or two control-implementations (that each have the 4 implemented-requirements)?

1 control-implementations with 2 implemented-requirements