SOA validation logging: reducing first-response latency

Posted on November 25, 2016 by Rick Jelliffe

XHTML failed as a delivery dialect of HTML because XML is defined so that, strictly, you do not deliver a document until you know it is well-formed. That did not fit in with what WWW users need: they want the parts of the page rendered as soon as possible, as quickly as the packets arrive. Schematron has the same issue: you need to process the entire document before you get the first result. There is no opportunity to take advantage of parallelism.

Actually, Schematron implementations can take other strategies. The most common implementation, my Schematron Skeleton implementation promoted on this site, provides an option so that you can terminate after generating the first error. Or an implementation could make a separate SVRL output document for each pattern, say: in recent SAXON that is likely to cause each pattern to run in a separate thread; in other implementations it might allow some SVRL documents to be closed before others.

But another method occurs to me: when an assertion fails, use the XPath document() function (or modern equivalent) to retrieve a dummy resource from a web service: provide the assertion failure records as URL parameters. So as soon as an assertion fails, the service receives information which it can then act on. So this reduces the latency of the best case (the first assertion to fail) without affecting the worst case (the last assertion to fail.)

When might this be useful? Perhaps it might be useful if you have a large document and you want to halt processing only if the number of errors goes over some threshold. Or if you have an interactive editor and want to take the user to the first error ASAP; or similarly some real-time feature recognizer where you want to take the user to the first interesting feature that comes up ASAP. Many IDEs support asynchronous error reporting from compilers; a stream of validation messages rather than a document may fit in better. Or if you have some kind of messaging system, where you will send reports of different assertion failures to different addressees (say, keyed off the role attribute value.)

Architecturally, this method splits the Schematron in half, so that the reporting side is an SOA service, that could be coded separately to the Schematron assertion testing side. That may have some Access Control benefits too, I guess. SVRL has been very successful, because it integrates into an XML tool chain: perhaps integrating into an SOA or messaging environment would have some use too.

How to implement it? The XSLT Skeleton implementation already has an API layer to make this convenient.