Schematron and abstract patterns

[o-sapov]

Hi,
I've developed a customized version of a schematron framework integrated-styleguide which your may download here: schematron.zip. The XSpec tests (./unit_tests/main.xspec) unfortunately fail here for abstract rules . Running this I get a transformation error (cf. ./unit_tests/cmd_error_output.txt). It says that among others the 'parameters' elements are not recognized. I suppose those are the <parameters> in ./src/rules/library.sch.

While testing this issue, I've created a simplified version of the framework (schematron_simplified.zip). Interestingly, the transformation here does not break as above but the scenario (@label=clef)) with an abstract rule always fails, either I set <x:expect-not-assert id="clef_1"/> or <x:expect-assert id="clef_1"/>which actually should pass for the first case. Just for verifycation there is an another scenario (@label=tie) which is not an abstract rule and which subscenarios are evaluated correct.

I use oXygen 20.1 with XSpec add-on 2.0.0. Nevertheless, I get the same result when using the native XSpec 2.2.4 and saxon-he-10.8 from command line.

[galtm]

Hi, @o-sapov.

Sorry you didn't receive any response to this issue in a very long time.

Using your two ZIP-files, I was able to reproduce the error message and the test failure with Oxygen 26.0. I believe the problems are coming from how the default "skeleton implementation" of Schematron resolves abstract patterns.

Both problems went away when I swapped out the skeleton implementation and instead used the SchXslt implementation of Schematron at https://github.com/schxslt/schxslt. At least the 2nd problem (with your simplified ZIP-file) looks like Schematron/schematron#6. The 1st problem might be, too, but I haven't investigated that thoroughly. In the 1st case, the hard error went away and the test has an ordinary failure, but it looks to me like a legitimate test failure.

The skeleton implementation is not being maintained, whereas the SchXslt implementation is actively maintained. Are you able to use the SchXslt implementation for your work?

Workaround

Command-line instructions for using SchXslt with XSpec are in the Using another implementation of Schematron section in the XSpec documentation.

If you are running XSpec using an Oxygen transformation scenario with Type=ANT, you can adapt those instructions. Download an unzip SchXslt as the section linked above describes. Then, clone the Oxygen transformation scenario and set the transformation scenario dialog's Additional Ant arguments field to the SchXslt-related arguments mentioned in the section, which are -Dxspec.schematron.preprocessor.step1, -Dxspec.schematron.preprocessor.step2, and -Dxspec.schematron.preprocessor.step3.

[o-sapov]

Thank you, I'll check the options you've provided.

[o-sapov]

Should the parameters be defined with or without the prefix -?

In both cases, the transfomation succeeds, but I am not sure which schematron implementation is used. Is it possible to verify?

Also, the scenario with expect-not-assert fails but succeeds when switching to expect-assert, which is incorrect. I'm trying to investigate why.

[galtm]

Should the parameters be defined with or without the prefix -?

Thanks for the screen capture. I see that you added parameters on the Parameters tab. That seems logical, but actually they should be in the Additional Ant arguments field on the Options tab.

The value I have in that field is the following, all on one line:

-Dxspec.schematron.preprocessor.step1="C:\temp\schxslt-1.9.5-xslt-only\schxslt-1.9.5\2.0\include.xsl" -Dxspec.schematron.preprocessor.step2="C:\temp\schxslt-1.9.5-xslt-only\schxslt-1.9.5\2.0\expand.xsl" -Dxspec.schematron.preprocessor.step3="C:\temp\schxslt-1.9.5-xslt-only\schxslt-1.9.5\2.0\compile-for-svrl.xsl"

Verify that SchXslt is being used

An ad hoc way to verify that the SchXslt implementation is taking effect is:

1. Temporarily add or modify some <x:expect-...> element to make it fail (e.g., I changed count="2" to count="200")
2. Run the test using your modified transformation scenario
3. Inspect the Result section on the left side of your report. If you see text that says xmlns:schxslt or SchXslt then the test used SchXslt.

[o-sapov]

Thank you!
Now I could set it up properly. The tested scenario works as expected.

[o-sapov]

One thing I am curious about:
Our team uses Schematron while editing in oXygen. It still uses the skeleton schematron implementation. When the tests are driven by another engine which is eventually used for validation, how risky is it that something goes wrong? What do you think?

[galtm]

Good point: in general, there is a risk that tests passing with SchXslt can mask problems (false positives or false negatives) that the end users of the schema experience with Oxygen using the skeleton implementation.

I wanted to see what Oxygen actually did with your Schematron code. Based on your simplified sample, in the main.xspec file's label="clef" scenario, I created a separate XML file whose content is from the scenario's <x:context> element:

<?xml version="1.0" encoding="UTF-8"?>
<mei:clef line="2" shape="G" xml:id="clef_in3_gcj_ntb"
  xmlns:mei="http://www.music-encoding.org/ns/mei"/>

Validating this separate XML file in Oxygen 26.0 against your main.sch schema passed. That means that Oxygen doesn't exhibit the bug for that context, despite using the skeleton implementation. Why? My hunch is that it's because SyncroSoft modified the skeleton implementation to make it work better with their Oxygen products.

If XSpec and Oxygen are the only things in your tool chain that consume your Schematron code, then maybe this particular piece of schema code doesn't actually present much risk at all because XSpec has a fix (SchXslt) and Oxygen has a fix (SyncroSoft's modifications).

It would be simpler if XSpec and Oxygen both used SchXslt, though. Perhaps you can ask Octavian if there is any update on the issue he mentioned in https://www.oxygenxml.com/forum/viewtopic.php?p=67450 and/or keep an eye on schxslt/schxslt#30 and/or investigate setting up a custom validation engine (see the doc linked from the forum topic I just mentioned) for your team's use.

[galtm]

@o-sapov : Now that your test runs correctly with SchXslt, is it OK to close this issue?

[o-sapov]

Yes, thank you very much for the support.

[galtm]

You're welcome! And the music encoding looks interesting, too. : )