XSpec testing Schematron is a bit more complicated than testing XSLT, because Schematron itself is not a simple transformation. By means of a transformation, a set of rules is applied to a document or XML fragment (for testing), with that transformation (Compiled Schematron XSLT) being produced by a transformation (the Schematron compiler - SchXSLT here).
The current workflow is implemented in Ant or using shell-script (batch file) logic, and looks like this. This works well and is expected to be stable:
The flowchart diagram below was made based on inputs provided by @galtm - thanks!
graph LR
classDef interim fill:whitesmoke,stroke:grey
classDef output fill:lightsteelblue,stroke:black,stroke-width:2
report[Test report]:::output
testingXSLT[Compiled\nXSLT]:::interim
sch[Schematron\nschema]
schXSLT[Compiled\nSchematron\nXSLT]:::interim
xspecFile[XSpec\nsource file]
compiledXSpec[XSpec test set]:::interim
sampleXML[Sample XML]
testingXSLT --executes--> report
schXSLT-.->|imports|testingXSLT
compiledXSpec --compiles--> testingXSLT
sch--SchXSLT-->schXSLT
xspecFile --translates--> compiledXSpec
sch-.-|references|xspecFile
sampleXML-.-|embeds or\nreferences|xspecFile
sampleXML-.-|embeds or\nreferences|testingXSLT
As depicted, a ready-to-go XSLT (Compiled XSLT) imports a ready-to-go XSLT (Compiled Schematron XSLT produced using the commodity tool) as if it were a compiled XSpec XSLT importing a target XSLT. In the usual case this is the XSLT under test -- and indeed ordinarily we would run the Schematron by producing and running it. In this case, however, the upstream compiled XSLT does not exist unless the processor compiles the upstream Schematron to produce it. An XSLT that does not exist is difficult to import from another module.
Rather than introduce a file-system or other runtime dependency into XProc - which would 'prefer' to be entirely side-effect-free - the pipeline here modifies the (compiled) XSLT on the fly, replacing its xsl:import instruction with the literal templates to be imported.
Closer examination and testing can help to determine if this approach is fragile, and how to mitigate it if it is.
For example, if xsl:apply-imports ever appears in the generated code (Schematron as compiled into XSLT), it would presumably require rewriting because no longer functional.
Similarly, Schematrons that rely on complex XSLT especially when it is modular (xsl:include, xsl:import) -- these remain to be tried and YMMV.
The hope going forward is that this work (trying and testing, analysis and implementation) can all be done -- with XProc -- without affecting 'mother code' -- learn as we go.