Validate uncaught exception for errors found in Schematron

[jordanpadams]

Checked for duplicates

Yes - I've already checked

🐛 Describe the bug

When I did performed validate against the test data below with the test schemas/schematrons, validate raises an exception.

🕵️ Expected behavior

I expected validate to catch and throw a more reasonable error message (if possible).

📜 To Reproduce

./validate --schema schemas/*.xsd --schematron schemas/*.sch --target julian_dates_unit_check_VALID.xml --skip-content-validation

See test data below for the schemas and test data. Warnings are expected from the execution because the schemaLocations and schematron prolog are missing, but it should still run without exception.

🖥 Environment Info

Mac osx

📚 Version of Software Used

v3.4.1

🩺 Test Data / Additional context

Archive.zip

🦄 Related requirements

• 🦄 As a user, I want to throw a WARNING when a product's schematron version does not match the schema version #628

⚙️ Engineering Details

Note: The rule in the schematron that Saxon doesn't like (even though I think it is valid XPath) is:

  <sch:pattern>
    <sch:rule context="sb:SB_Metadata//.[ends-with(name(),'_JD')]">
      <sch:assert test="@unit eq 'julian day'">
        <title>sb:SB_Metadata//.[ends-with(name(),'_JD')]/Rule</title>
        The attribute "<sch:value-of select="name(.)"/>" must be specified with "unit='julian day'".</sch:assert>
    </sch:rule>
  </sch:pattern>

If you update that rule to use * instead of . it works just fine:

  <sch:pattern>
    <sch:rule context="sb:SB_Metadata//*[ends-with(name(),'_JD')]">
      <sch:assert test="@unit eq 'julian day'">
        <title>sb:SB_Metadata//.[ends-with(name(),'_JD')]/Rule</title>
        The attribute "<sch:value-of select="name(.)"/>" must be specified with "unit='julian day'".</sch:assert>
    </sch:rule>
  </sch:pattern>

[cgobat]

I actually don't think the former (using .) is correct. In order to identify all elements whose name ends with "_JD" (as seems to be the intent), the latter (using *) is the way to do it—in other words, I don't think this was a problem with Saxon/validate.

On the SB side, it looks like this was already addressed in commit 96c7ce5, so the problem should be resolved in new builds of that dictionary.