Some Metaschema-based techs including OSCAL use Metapath syntax in targeting constraints, which break the current (beta-version) InspectorXSLT.
This happens any time a path does not conform to the definition of the syntax for selection patterns) in XSLT, which is narrower than XPath, for example forbidding the form.
Describe the bug
Some Metaschema-based techs including OSCAL use Metapath syntax in targeting constraints, which break the current (beta-version) InspectorXSLT.
This happens any time a path does not conform to the definition of the syntax for selection patterns) in XSLT, which is narrower than XPath, for example forbidding the form.
https://github.com/usnistgov/OSCAL/blob/f159b28948cb0034370fb819a45bfdaeaef5192a/src/metaschema/oscal_ssp_metaschema.xml#L291C8-L291C8
and then there is, in an index definition --
https://github.com/usnistgov/OSCAL/blob/f159b28948cb0034370fb819a45bfdaeaef5192a/src/metaschema/oscal_ssp_metaschema.xml#L49C47-L49C280
A couple of possible mitigations:
These are not exclusive and the first could be done while planning the second.
The option of rewriting the patterns 'by hand' might also be considered as a mitigation, which doesn't require parsing.
Who is the bug affecting?
Anyone with a metaschema using the problematic expressions.
This includes OSCAL users, a significant constituency.
What is affected by this bug?
InspectorXSLT is not available as an option for these users.
When does this occur?
Reliably.
How do we replicate the issue?
Try composing and producing an InspectorXSLT from an OSCAL schema.
NB: a solution should be accompanied by unit tests!
(More details available and tbd.)
Expected behavior (i.e. solution)