Add support for a command-line parameter "mark-phase" to name a phase that is used to validate the SVRL generated by the validation. Add a phase option like #ALL-EXCEPT that validates with all patterns except the ones active in the mark phase. This should be performed by the generated XSLT, not by the calling shell.
This allows a two-phase validation. First the document is validated with whatever patterns or phases are required, and the SVRL generated. Then that SVRL is validated with the "mark-phase". This turns Schematron validation into a map-reduce kind of operation, I guess. Marking is used in the sense that you have found the patterns in the first pass, and then you want to assign the significance or summarize the results in the second pass. It would generate SVRL (but the location links would be to the SVRL from the first pass, I guess.)
The uses for this are where you want to use the results of one validation (or pattern match) as part of some conditional. The marking assertions could pass through the text from the original SVRL, but not things like attribute values.
This is part of a general problem with Schematron that we have relied on some shell like XProc or DSDL to be a nice layer to handle the smarts. But it is a step too far for most systems and users.
Add support for a command-line parameter "mark-phase" to name a phase that is used to validate the SVRL generated by the validation. Add a phase option like #ALL-EXCEPT that validates with all patterns except the ones active in the mark phase. This should be performed by the generated XSLT, not by the calling shell.
This allows a two-phase validation. First the document is validated with whatever patterns or phases are required, and the SVRL generated. Then that SVRL is validated with the "mark-phase". This turns Schematron validation into a map-reduce kind of operation, I guess. Marking is used in the sense that you have found the patterns in the first pass, and then you want to assign the significance or summarize the results in the second pass. It would generate SVRL (but the location links would be to the SVRL from the first pass, I guess.)
The uses for this are where you want to use the results of one validation (or pattern match) as part of some conditional. The marking assertions could pass through the text from the original SVRL, but not things like attribute values.
This is part of a general problem with Schematron that we have relied on some shell like XProc or DSDL to be a nice layer to handle the smarts. But it is a step too far for most systems and users.