SVRL element for compilation and runtime errors

[rjelliffe]

This is a proposal to add a specific element to SVRL that implementers can use to convey compile-time and run-time errors in a Schematron schema.

<!ELEMENT  sch:problem (diagnostic*, %foreign;*) >
<!ATTLIST sch:problem
      severity ("fatal" |  "error" |  ... )  "fatal"  #REQUIRED
      in  IDREF #REQUIRED 
      at  ("context" | "test" | "value | ..." ) "test"  #REQUIRED
      text CDATA #IMPLIED
      code CDATA #IMPLIED 
      message CDATA #IMPLIED >

E.g. we have rule with bad xpath <sch:assert id="a4" context="if (x = y) then 1 else">....

  <sch:problem  in="a4" at="test" text="if ( x = y) then 1 else"  message="incomplete XPath" >
     <sch:diagnostic>The results are not reliable w.r.t. x and y elements, because of some system or programming problem.</sch:diagnostic>
      <java:exception message="  ...... "/>
  </sch:problem>

This would be allowed anywhere in SVRL, and is aimed at XPath and missing IDs reports.

It allows a Schematron implementation to take advantage of the newer XSLT try/catch blocks so that a programming error does not necessary cause a complete abort of the validation, and so that appropriate user-oriented messages can be generated rather than relying on the logging or exception-reporting chain (which often have no user-facing visibility and consequently no way to handle problems in-band by consuming applications in an XML pipeline. It allows all-XML pipelines.

It obviously allows run-time dynamic reporting of programming errors (e.g. for an XSLT engine that only reports XPath errors when they are evaluated) but it allows a runtime SVRL report to be generated even when loading and initializing the compiled program (e.g. for an XSLT engine that checks Xpaths at load-time.)

Indeed, an implementation could generate an SVRL report at compile time, reporting only the sch:problem elements.

For example, an implementation might do this:

   <xsl:try>
       <xsl:variable name="dummy-element" as="element()"><x/><xsl:variable>
       <xsl:if test="if ( x = y) then 1 else"><!--do nothing--></xsl:if>
       <xsl:catch>
           <sch:problem ... at="if (x - y) then 1 else" message="{$err:message}" code="{$err:code}"   >
              <sch:diagnostic>A fatal compile time problem occurred. Incorrect syntax for XPath. This is likely a programming error. </sch:diagnostic>
           </sch:problem>
       </xsl:catch>
   </xsl:try>

Currently, an implementation might be struggling to know whether to use failed-assert or whatever, which might cause tag abuse.

[AndrewSales]

See also Schematron/schema@b3b941d#diff-60420154505f5e06bb937bf6ab79f51f0aad7f611f31a25e982b72a6010fd4a7R91-R98.

[dmj]

This is a proposal to add a specific element to SVRL that implementers can use to convey compile-time and run-time errors in a Schematron schema.

+1 for this.

The standard characterizes a Schematron validator as a function returning three possibles values: "valid", "invalid", or "error" (Section 6.1). We currently have no way of expressing the value "error" in SVRL.

The modified schema allows a SVRL error-element as child of the SVRL active-pattern element. However: An error might also occur outside an active pattern, e.g. while calculating the value of a variable.I would thus make the SVRL error element a child of SVRL schematron-output, not of active-pattern.

[AndrewSales]

I would thus make the SVRL error element a child of SVRL schematron-output, not of active-pattern.

I think it's still worth retaining it in the context of svrl:active-pattern, to meet the requirements of #47, but agree it's useful as a child of svrl:schematron-output: see Schematron/schema@bb90662.

[rjelliffe]

I think there are two different situations:

1. The Schematron schema or engine has a problem.

• Some are Compile-time error.

• Some are dynamic: Nan number, or function not allows list as parameter, etc.

  • Use /svrl:schematron-output/svrl:problem without attempting any nesting;
  • allow message-terminate or other exception to crash XSLT engine and present just the problem, if that is all an implementation. In fact, we probably want to suppress any SVRL results if there is a problem, so that there is no chance of false positive validity.

2. The resource to be validated has a problem. Runtime error.

• Use svrl:active-pattern/svrl:problem

[AndrewSales]

I think there are two different situations:

So I've changed the issue title.

[AndrewSales]

I'll add a mapping for /svrl:schematron-output/svrl:error to the table in Annex D.