fix: make ComponentDefinition and MappingCollection implement IOscalInstance

[david-waltermire]

Summary

• Add metaschema bindings for component-definition and mapping-collection to extend AbstractOscalInstance, which implements IOscalInstance
• Add test case to verify the fix for validating ComponentDefinition documents with import-component-definitions

Problem

When validating a ComponentDefinition with import-component-definitions that uses fragment references (href="#uuid"), the constraint evaluation calls resolve-reference() which attempts to cast the root ComponentDefinition to IOscalInstance. This fails because ComponentDefinition (and MappingCollection) did not implement IOscalInstance.

The error was:

ClassCastException: class gov.nist.secauto.oscal.lib.model.ComponentDefinition 
cannot be cast to class gov.nist.secauto.oscal.lib.model.IOscalInstance

Solution

Add bindings in oscal-metaschema-bindings.xml for:

• component-definition → extends AbstractOscalInstance
• mapping-collection → extends AbstractOscalInstance

This matches the pattern used by other OSCAL root types (Profile, SystemSecurityPlan, AssessmentPlan, etc.).

Test plan

• testComponentDefinitionImplementsIOscalInstance - Verifies ComponentDefinition implements IOscalInstance
• testValidateComponentDefinitionWithImport - Verifies validation completes without ClassCastException
• Full test suite passes (49 tests, 0 failures)

Fixes: metaschema-framework/oscal-cli#192

Summary by CodeRabbit

• New Features

  • Added metaschema binding support for component definitions and mapping collections, extending OSCAL model support.

• Tests

  • Added tests verifying component-definition import behavior and validation to prevent class/validation errors.
  • Added test fixtures supporting component-definition import and validation scenarios.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Added metaschema assembly-bindings for component-definition and mapping-collection, and new tests + fixtures that validate component-definition import behavior and prevent a ClassCastException during validation.

Changes

Cohort / File(s)	Summary
Metaschema binding configuration src/main/metaschema-bindings/oscal-metaschema-bindings.xml	Added define-assembly-binding entries for component-definition (points to oscal_component_metaschema.xml) and mapping-collection (points to oscal_mapping_metaschema.xml), both extending gov.nist.secauto.oscal.lib.model.AbstractOscalInstance.
Test implementation src/test/java/gov/nist/secauto/oscal/lib/validation/ComponentDefinitionImportTest.java	Added tests: testComponentDefinitionImplementsIOscalInstance() (asserts loaded ComponentDefinition implements IOscalInstance) and testValidateComponentDefinitionWithImport() (validates component-definition with import without throwing ClassCastException).
Test resources src/test/resources/content/issue-192/base-component-definition.json, src/test/resources/content/issue-192/component-definition-with-import.json	Added JSON fixtures: a base component definition and a component-definition that imports the base file (used by the new tests).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Review the two new assembly-binding entries for correct metaschema references and fully-qualified base-class name.
• Check test assertions and resource paths in ComponentDefinitionImportTest.java to ensure they load the intended fixtures and exercise import resolution.
• Verify JSON fixtures' structure matches the metaschema expectations (top-level component-definition, import-component-definitions, and back-matter link).

Suggested reviewers

• aj-stein

Poem

🐰 I hopped through bindings, tidy and keen,
Added a link where a cast once went mean,
Tests gave a nudge, fixtures in tow,
Now imports behave, steady they go. 🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: making ComponentDefinition and MappingCollection implement IOscalInstance through metaschema binding updates.
Linked Issues check	✅ Passed	The PR fully addresses issue #192 by adding metaschema bindings for component-definition and mapping-collection to extend AbstractOscalInstance, implementing IOscalInstance, and includes validation tests confirming the fix.
Out of Scope Changes check	✅ Passed	All changes align with the stated objectives: metaschema binding updates, implementation of IOscalInstance interface, and test resources are directly related to fixing the ClassCastException issue.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6a1b0a9 and a93709b.

📒 Files selected for processing (4)

• src/main/metaschema-bindings/oscal-metaschema-bindings.xml (2 hunks)
• src/test/java/gov/nist/secauto/oscal/lib/validation/ComponentDefinitionImportTest.java (1 hunks)
• src/test/resources/content/issue-192/base-component-definition.json (1 hunks)
• src/test/resources/content/issue-192/component-definition-with-import.json (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• src/test/java/gov/nist/secauto/oscal/lib/validation/ComponentDefinitionImportTest.java

🔇 Additional comments (4)

src/test/resources/content/issue-192/base-component-definition.json (1)

1-19: LGTM!

Test fixture is well-formed and includes all required OSCAL component-definition fields. UUID and timestamp formats are correct.

src/main/metaschema-bindings/oscal-metaschema-bindings.xml (2)

116-120: LGTM!

Component-definition binding correctly extends AbstractOscalInstance, aligning with other OSCAL root types (profile, system-security-plan, etc.). This directly addresses the ClassCastException issue.

---

177-184: LGTM!

New mapping-collection binding is properly structured and consistently extends AbstractOscalInstance. Placement as a new metaschema-binding section is appropriate.

src/test/resources/content/issue-192/component-definition-with-import.json (1)

10-27: Test fixture relative path resolution is correct.

Both fixture files are properly placed in the same directory (src/test/resources/content/issue-192/), which allows the rlink reference to base-component-definition.json to resolve correctly. The test testValidateComponentDefinitionWithImport() validates this scenario, confirming that the import with relative path resolution works without raising ClassCastException.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[brian-ruf]

LGTM