Allow severity to be user-defined
AndrewSales opened this issue · comments
I suggest extending attribute severity beyond the controlled list given at https://github.com/xproc/xvrl/blob/master/schema/xvrl.rnc#L77.
Use case: in business rule-based validation such as Schematron, the pre-defined set of severity levels is not present and may be specified by the schema author.
Given the constraint:
<assert test='alles[paletti]' role='nee'>Meine Datei tut weh</assert>
where @role (or @flag) describes severity, the user-defined level nee may have different semantics depending on the consumer of the validation report or its context (e.g. particular point in a workflow), for instance. Downstream processes might also interpret this accordingly, and this interpretation could alter over time: what yesterday was ignorable might today have become critical.
I don’t want to give away the hard-fought controlled vocabulary so easily.
What about allowing an optional free-text @role attribute alongside a controlled (and also optional) @severity attribute?
The SVRL→XVRL conversion XSLT can then have a boolean parameter map-role-to-severity that, if set to true, will map a role value of 'Warning', 'warn', and 'warning' to a severity value of 'warning', a role value of 'err', 'error', 'Error' to 'error', etc., while keeping non-matching, workflow-specific role attributes unaltered.
When generating XVRL from schema validation messages, the severity level is in the eye of the beholder anyway. In our reports we can configure whether all messages that result from a given schema validation will be flagged as an error (which is the default) or as a warning.
This seems like a reasonable workaround.
What about @flag, though? The spec isn't prescriptive about the distinction between it and @role - severity is only discussed in relation to flag, and popular editors only appear to support role here - but it would be good not to leave it out.
Then the parameter be called map-to-severity with space-separated tokens role, flag and possible other arcane SVRL attribute names.
Example: For a parameter map-to-severity="flag role" and SVRL attributes role="foo" and flag="ERROR", an attribute severity="error" is generated. The remaining role attribute will either be converted to <category vocabulary="svrl:role">foo</category> or to an attribute svrl:role="foo". Map to category would be preferable if @role were localizable, which it isn’t.
Another example: For a parameter map-to-severity="flag role" and SVRL attributes role="error" and flag="foo", attributes severity="error" and svrl:flag="foo" are generated.
So the rule is: Try to map the attributes with names given in map-to-severity to severity and use the first that could be mapped. Create (an) @svrl:… attribute(s) for the other attribute(s) that are given in map-to-severity but whose string value does not correspond to the severity controlled vocabulary.