Metaschema composition fail: exception handling induces runtime error

[wendellpiez]

Describe the bug

Reported on a metaschema in progress:

Generated compiled Schematron '/oscal/build/metaschema/toolchains/xslt-M4/validate/metaschema-composition-check.sch' as '/oscal/build/metaschema/toolchains/xslt-M4/validate/metaschema-composition-check-compiled.xsl'.
Schematron validation failed for metaschema 'src/metaschema/oscal_complete_metaschema.xml'.
Error evaluating ((xsl:copy-of, ...)) on line 59 column 35 of metaschema-build-refs.xsl:
  XTDE0410: An attribute node (in-xml) cannot be created after a child of the containing
  element. Most recent element start tag was output at line 111 of module metaschema-build-refs.xsl
An attribute node (in-xml) cannot be created after a child of the containing element. Most recent element start tag was output at line 111 of module metaschema-build-refs.xsl

This should not happen: the process should conclude even if outputs are marked with EXCEPTIONs.

A metaschema that produces the error is here (a WIP branch): https://github.com/Rene2mt/OSCAL/tree/860-identifier-scoping-documentation/src/metaschema

Who is the bug affecting?

Anyone developing a metaschema who inadvertantly writes one of the offending constructs, will be denied a composed metaschema, but not given any decent information for remediation.

What is affected by this bug?

Can't compose the metaschema! Can't check it for correctness or use it.

When does this occur?

TBD. Line 111 indicates the fail in this case is due to a dangling (orphan) field reference, so that is something to try.

How do we replicate the issue?

A metaschema that produces the error is here (a WIP branch): https://github.com/Rene2mt/OSCAL/tree/860-identifier-scoping-documentation/src/metaschema

But replication in a small standalone instance might be helpful for isolating it.

Expected behavior (i.e. solution)

No runtime error. Instead, a successful conclusion with EXCEPTIONs noted.

Other Comments

Because of the first-attributes-then-contents rule, the apply templates here needs to be broken between those producing attributes and those producing elements (possibly in two modes).

[david-waltermire]

Need to confirm that this is still occurring, and if so unit test it and fix it. The implementation should give a meaningful runtime message instead of the traceback.

[wendellpiez]

Should this be spiked to confirm current status, or is it closable?