How does Schematron fit in with Scrum?
This a follow-up to Error Messages and Diagnostics should be Inputs to the Developer not Outputs. According to that, error messages and diagnostics should be provided through the Product Manager as details on the appropriate Product Backlog items.
In Scrum terms, you want to add Schematron validity as part of the Definition of Done (i.e. the criteria used by the development team to know that the current increment of software is really completed and potentially ready for release) for all work in the project.
It might be something like this
All XML documents produced must be valid against their simple document schemas on the generated XML document (not the DOM), whether DTD, XSD, ISO RELAX NG, ISO
Schematron or some custom schema. The software should by default validate and firewall incoming and outgoing XML documents, and log the error, but may have an option to bypass.
(An exception may be made for small, simple ephemeral documents that are consumed
as soon as they are produced, which must be validated by unit tests. DOMs may also
be validated as part of unit testing. )All XML documents produced must be valid against business rules tests on the generated XML document, whether ISO Schematron, XSD 1.1 assertions, OASIS
Content Assembly Mechanism, or some custom rules system. The software should by default
validate and firewall incoming and outgoing XML documents, and log the error, but may have an option to bypass. The business
rule should be expressed in terms that are clear to the expected recipient of assertion
failure messages.
(An exception may be made for small, simple ephemeral documents that are consumed
as soon as they are produced, which must be validated by unit tests. DOMs may also
be validated as part of unit testing.)
If you are using some subset of a large standard schema, or while your application only accepts subsets of some larger schema, you may also want to have a similar rule for input firewalling: rejecting input documents (real or test) that have features that are not implemented yet. It depends on whether this is an issue for your system. (These kind of assertions are implementation guards rather than business rules or schema rules.)
There are other rule possible too, which may be more suitable if your sprint involves developing new schemas:
For business rules, any code lists maintained by external organizations must be maintained using the UBL Code List Methodology.
There may be other wrinkles and exclusions. You need to come up with a common understanding of the difference between a document schema rule and a business rule, being aware that standard schemas often have simple business rules embedded, such as lists of allowed attributes, which may mean you cannot be too strict about the partition.
It is increasingly common for Scrum teams to also have a Definition of Ready, which is the bottom-line acceptance level for items on the Product Backlog to be accepted into a Sprint Backlog. The more that the acceptance tests can be defined the better for estimating the tasks involved. So for Schematron, you just want to formulate the assertion texts. Don’t write a Schematron schema or any XPaths, just make a list in words, perhaps using a template like “An X should have Y, because/so that Z”.