Duplicate UUIDs in component definition test data files

[LAKSHJAIN14]

Description

Several component definition test data files in tests/data/json/ contain duplicate control-implementation UUIDs within the same document, which violates the OSCAL specification requirement that all UUIDs must be unique within a document.
In each case, two different components within the same file share the same UUID for their control-implementation objects. This appears to be a copy-paste oversight when the test data was originally created.

for eg. comp_def_a.json, comp_def_b.json

Current behaviour

• trestle import correctly rejects these files via DuplicatesValidator in duplicates_validator.py, which checks for unique UUIDs using ModelUtils.has_no_duplicate_values_by_name(model, 'uuid').

• However, tests using test_utils.load_from_json bypass this validation entirely, so tests using these files pass despite the invalid data.

Questions for discussion

1.Should the duplicate UUIDs in the test data files simply be fixed (assign unique UUIDs to each control-implementation)?

2.Should other commands (e.g., ssp-generate, component-generate) also validate for duplicate UUIDs when loading component definitions, or is the import-time check sufficient?

@degenaro @vikas-agarwal76

[degenaro]

1. No. Tests using these data should now expect failure with revised code comprising this issue. Additional tests should be included with similar data files, but having fixed UUIDs. It's OK to rename tests to be commensurate with their purpose.
2. Yes. trestle should not produce invalid OSCAL documents, if import-time is insufficient to catch duplicate UUIDs.

@vikas-agarwal76 do you not concur?

[vikas-agarwal76]

@degenaro We need a discussion on this.

[degenaro]

@vikas-agarwal76 @LAKSHJAIN14 I put this issue on the list for Mar 10 Community meeting. https://docs.google.com/document/d/1XTYM7xnWlIqd-8Nn5-qtgvgk8kH3NSmYle5yZvaS7qs/edit?tab=t.0

[github-actions]

This issue has been automatically marked as stale because it has not had activity within 90 days. It will be automatically closed if no further activity occurs within 30 days.