✨ Highlights
This release updates the core framework to metaschema-java 3.0.0.M4, aligns the OSCAL bindings with OSCAL v1.2.1, fixes a profile multi-import validation bug, and consolidates control-selection/matching types into shared interfaces.
metaschema-java 3.0.0.M4
Updated the core Metaschema framework dependency to 3.0.0.M4 (#287). Notable changes brought in by M4:
- Performance instrumentation for constraint validation with
--sarif-timingCLI output (per-invocation, per-rule, and per-let timing in SARIF 2.1.0). - New
list-allowed-valuesCLI command built onAllowedValueCollectingNodeItemVisitor, which has been migrated from liboscal-java into metaschema-java'scoremodule — see the visitor-removal note below. - Metapath evaluation improvements that allow module-walk tools to evaluate OSCAL lets calling functions like
oscal:resolve-reference(@href)without raisingFOTY0013.
OSCAL v1.2.1
Updated the OSCAL submodule from v1.2.0 to v1.2.1 (#276). The submodule bump pulls in JSON schema corrections, assembly definition fixes, and constraint corrections. Binding configuration for select-control-by-id and matching was moved from the profile section to the control-common section to match OSCAL v1.2.1's consolidation of these definitions into oscal_control-common_metaschema.xml.
Profile Multi-Import Validation Fix
Fixes oscal-cli#250: when a profile imported two or more catalogs and used with-ids rather than include-all, validation incorrectly reported control identifiers on the second (and later) imports as missing. Root cause was that metaschema index names are document-global — both imports were attempting to build an index with the same name, the second was discarded, and subsequent with-id lookups resolved against the first import's catalog only. The fix replaces the index/index-has-key pair with an inline expect that uses the per-import $resolved-profile-import let binding to perform the lookup directly. (#282)
Shared Control-Selection Interfaces
Introduces IControlSelection and IControlMatching common interfaces in dev.metaschema.oscal.lib.model.control and renames the generated classes to make module relationships explicit:
ProfileSelectControlById→ControlCommonSelectControlById(used by profile'sInsertControlsand mapping'sGapSummary)SelectControlById→AssessmentCommonSelectControlById(used byReviewedControls)
Hand-written types (IControlCommonSelectControlById, AbstractControlCommonSelectControlById, new AbstractControlMatching) moved up to dev.metaschema.oscal.lib.model.control to match their scope. (#281)
Removal of AllowedValueCollectingNodeItemVisitor
The visitor has been removed from liboscal-java — it contained no OSCAL-specific logic and has been migrated upstream to metaschema-java's core module, where it is now available to all Metaschema-based projects without requiring a liboscal-java dependency (#280, originally #256).
Migration: Consumers should switch their imports from gov.nist.secauto.oscal.lib.metapath.item.AllowedValueCollectingNodeItemVisitor (or the dev.metaschema.oscal.lib.* equivalent) to dev.metaschema.core.metapath.item.node.AllowedValueCollectingNodeItemVisitor.
🐛 Bug Fixes
- Validate profile imports against their own catalogs (#282) by @david-waltermire
♻️ Refactoring
- Introduce
IControlSelection/IControlMatchingcommon interfaces (#281) by @david-waltermire - Remove
AllowedValueCollectingNodeItemVisitor(now provided by metaschema-java) (#280) by @david-waltermire
🔧 Build & CI Improvements
- Update OSCAL submodule to v1.2.1 (#276) by @david-waltermire
- Fix CI infrastructure: bump Trivy action and update FedRAMP profile validation test URL to
OSCAL-Foundation/fedramp-automation(#277) by @david-waltermire