metaschema allowed-values target attribute path validation

[GaryGapinski]

While inspecting OSCAL/src/metaschema/oscal_ssp_metaschema.xml I found something unexpected.

The <allowed-values> element has a target attribute which routinely contains what appears to be an XPath expression. The related metaschema XML schema (../../build/metaschema/toolchains/xslt-M4/validate/metaschema.xsd) indicates that the target attribute is a metaschema-path-type but these strings appear indistinguishable from XPath expressions.

Are all <allowed-values> element target attributes XPath expressions?

src/metaschema/oscal_ssp_metaschema.xml has what appears to be an XPath expression which is syntactically invalid (the expression ends in a right curly bracket rather than a right parenthesis). It seems unlikely that it would be a correct metaschema path.

Should this have been detected and corrected?

[wendellpiez]

@GaryGapinski this is a good topic for Lunch with the Devs or anywhere there is an interest in Metaschema.

The short version is that we have posited an expression language (naturally called 'Metapath') that would serve to address both XML and JSON flavors of OSCAL.

So far it is a clean subset of XPath 2.0, except adding a single function, called value(). We need this function because the nominal 'value' of a field in JSON or XML is found in the tree in a different way (and in XML it could be mixed content). We have left out variable references, the axes that do not look down (so permitting self::, child::, descendant:: and descendant-or-self::), and grouped steps apart from union steps (so we do a/(b|c)/d but not a/(* except c)/d.

However this is all in the context of development -- in this case, including the capability to cast from paths to address XML OSCAL to paths that address OSCAL JSON (as expanded into XPath JSON XML).

As for your question, actually the error (and there are more) has been detected, just not corrected yet. Indeed those paths (even when actual paths not random strings) have not been validated operationally yet, either.

[GaryGapinski]

Thanks @wendellpiez for the detailed explanation. I think AJ had shown me a reference to a related parser.

What had surprised me is that a flaw in a Metapath might preclude correct generation of documentation regarding <constraint>s. A pointer to the related (e.g., producing allowed values) transform(s) would be appreciated.