[Schematron] Schematron Message element: multiple message types per rule?

Rick Jelliffe rjelliffe at allette.com.au
Sat Jul 11 21:13:12 EDT 2009


I think this capability is already in Schematron.

Each assertion can take a role attribute. You could use this to label 
each assertion "caution", "error", "note" or whatever.

Furthermore each assertion can also link to one or more diagnostics 
messages. These can further be labelled with roles: you could use 
"loggedMessage" and "userMessage" for example, to distinguish different 
targets. All the diagnostics will go to the SVRL file, where they can be 
extracted by XSLTs if you don't want to write your own metastylesheet. 
You could certainly use the XSLT to order the diagnostics and messages 
by some ranking too.

Furthermore, if you want to group assertions, e.g. into severe and so 
on, Schematron provides a facility called "phases". It groups patterns, 
so that you can test against one set of patterns (one phase of 
validation) and then, depending on the results test another set of 
patterns. (You particular rules for selecting which phase to use needs 
to be done by the execution framework based on the results of the 
previous phase. It is not part of Schematron.)

In the current XSLT2 version of Schematron, it supports an experimental 
extension that also allows arbitrary properties to be transferred to the 
SVRL file. This allows the schema to specify arbitrary XML or text that 
can get carried over to the SVRL file, to help further automated processing.

Cheers
Rick Jelliffe


Juerg Tschumperlin wrote:
>
> Hi,
>
> Does anyone share a requirement similar to ours:
>
> Currently, a Schematron rule has one message. Whenever an rule is 
> triggered, a single message is produced and in our case returned to 
> the sender. However, there are different types of error messages, 
> requiring different actions by the application:
>
> - Some errors need to be displayed to the user. Useful, when the user 
> can rectify the error. (i.e. User message: “The birth date must be in 
> the past for client ‘123’.”)
>
> - Other errors cannot be rectified by the user, and require software 
> vendor intervention. (i.e. User message: “System error 3456. Please 
> contact your software vendor.” / Detailed technical message for the 
> vendor: “A invalid, duplicate address type ‘Mailing Address’ has been 
> detected for client ‘123’. Address types must be unique per client. ”
>
> I suggest supporting a distinction in multiple messages for a rule 
> allowing an arbitrary number of <Message> elements with a type= 
> attribute. Then an implementation can document the kinds of tests 
> (two, three, any number) it does with .SCH files and offer users to 
> specify type= for the particular kind of error supported by the 
> implementation.
>
> This idea could be taken one step further, allowing to distinguish 
> errors and warnings. Warnings would allow to process an instance 
> document while gradually tightening on non-essential data quality over 
> time by issuing warnings to the sender. Such error and warning levels 
> may require a separate attribute, i.e. rule ABC triggers an error when 
> triggered, rule DEF triggers a warning if triggered.
>
> Ideally, Schematron would return the highest level of discrepancy 
> found in any of the rules:
>
> - >= 1 Error found (i.e. don’t process, and return all messages 
> (errors and warnings) to sender),
>
> - >= 1 Warning only found (i.e. process the instance document, but 
> also send the warnings to sender)
>
> - No errors and no warnings found. (i.e. process instance document)
>
> I’m keen to hear whether other Schematron users have a similar 
> requirement?
>
> Regards,
>
> Juerg Tschumperlin
>
> Data Management Solutions
>
> Wellington, New Zealand
>
> www.d-m-s.co.nz <http://www.d-m-s.co.nz>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Schematron mailing list
> Schematron at eccnet.com
> http://www.eccnet.com/mailman/listinfo/schematron
>   



More information about the Schematron mailing list