Schematron uptake is on the increase, and the betas implementation of ISO Schematron is chugging away. The relevant working group at ISO (ISO/IEC JTC1 SC34 WG1) has asked me to look into preparing an update for the standard; most of the other ISO DSDL family of schema languages have just been through a round of corrections based on initial experience, and I want to prepare something by the end of May.
There won’t be any changes that would break existing ISO Schematron schemas. And I don’t think there would be any extra logical apparatus or changes to the class of logic required; and certainly nothing that would prevent implementation in XSLT 1 by default.
I am interested in gathering a wish list, especially things where you have extended Schematron (i.e. your requirement was strong enough that you actually wrote some code!) Please let me know.
The candidates I see at the moment include:
- A new annex with the Query Language Binding for XSLT2.
- Editorial corrections, in particular changes coming from Murata’s Japanese translation for JIS. (Translation involves one of the best kinds of review a standard can get.)
- The new Schematron-Love-In mailing list has has some suggestions. For example, some users would like SVRL to be more thorough and there are some sentences or concepts in the standard that are perfectly clear to me (as the editor) but which apparently require mind-reading abilities.
- The W3C Rules Interchange Format RIF core design is a source of review material too. I haven’t participated with that group at all, because the “rules” aspect of Schematron is the least interesting part of it: indeed, Schematron is based on providing a very simple framework which provides extra-logical abstractions (patterns, phases, diagnostics, abstract patterns) and with an emphasis on ready implementability, rather than any concern with exposing a formal class of logic. Now, the ISO Schematron standard does specify Schematron using predicate logic (this is one thing that I expect the Japanese review will tighten up), so my intent is that the spec does not ignore logic-theoretic categorization, but Schematron always errs on the side of pragmatism: what abstractions will help users?, what low-hanging fruit does XSLT and XPath allow?, what source code actually exists that demonstrates implementability and actual requirements? I certainly expect that some uncomplicated RIF ruelsets may be be convertible into Schematron, but I wouldn’t think that Schematron to RIF would provide much value, at the moment. There are a couple of ideas in the RIF that are of interest however: in particular, whether we should add an element “reject” with the same operation as “report” to allow implementations to fail validity where a reject test succeeds, but when a report fails. (This would also remove one function that @role can perform.)
- A couple of recent implementation projects that Topologi and Allette Systems have been doing, integrating Schematron into a larger cradle-to-grave (client<->analyst<->developer<->accountant<->client ) may bring up some issues.
I would be keen to see Schematron's XML reporting format broken out into a separate spec that could then be enhanced to be a general format for reporting validation errors, business rule failures, etc.
Cheers, Tony.
I am wondering whether SVRL is the right base for this, actually. Tony has a language he uses, and ZVON had their language too. And W3C have a reporting framework language, and the Ant task for Schematron also has a wrapper for multiple files. Furthermore, SVRL is very Schematron-specific, and if one of my aims is to be able to convert all DSDL languages into a single XSLT script, it makes sense to have a common reporting language.
This may not be part of the ISO Schematron standard, but it's very useful: an updated Report Generator (error browser) for SVRL. I've browsed around on schematron.com and googled around to find such a stylesheet.
For the old schematron, there was David Carlisle's schematron-report.xsl. But it doesn't seem to work with SVRL. I could experiment with modifying schematron-report.xsl to import iso_schematron_skeleton.xsl instead of schematron-skeleton-1.5.xsl. Seems like it would be handy to have an approved and ready-to-go version though.
Have I just missed it somewhere?
P.S. It appears from Dave Pawson's schematron process diagram (http://www.schematron.com/validators/process.svg) that rendering SVRL into a form the end user can read is not even considered part of the process. I can understand that every standard needs a limited scope, but surely there is a need (be it outside the standard) for a stylesheet to render SVRL into something human-readable. (Modifying schematron-report.xsl to import iso_schematron_skeleton.xsl didn't work, by the way.) Especially since the existing stylesheets are difficult to understand, with their multiple layers of imports and code generation.