|
That would be tough in XSLT, because you can't put variables in template rule match conditions. The stylesheet that was evaluating the target document wouldn't know what it was supposed to look for until after it read the rules document, and if the stylesheet's specification of what to look for in the target document (that is, the @match value of the xsl:template element) can't be created on the fly using the flexibility of something like a variable, this approach won't work.
Because of the easy availability of the Xalan and Saxon Java source, it shouldn't be too difficult for someone comfortable with Java to write an app that reads the rules file, runs the generating stylesheet to create the rules-checking stylesheet in memory, and then runs that against the target document. Because this app doesn't need to create a disk file version of the rules-checking stylesheet, it would give the appearance of doing what you describe. I believe this is how Jing implements Schematron.
If you've got large volumes of data to deal with, creating the intermediate stylesheet does have some advantages, because you avoid the re-conversion of the rules file every time you need it and therefore use few cycles. (And, you can use a C-based XSLT processor like libxslt or Xalan C, which can give you additional speed.)
By the way, in the course of some private e-mail discussions today, I realized that the title of the column is somewhat misleading. Schematron 1.5 is a rules-based schema language, and the column is looking "under the hood" of a specific Schematron implementation that happens to be the most well-known one because it's free, doesn't require new software, and is the reference implementation. The column is not looking "under the hood" of the schema language itself, so I apologize (mostly to Rick J!) if I encouraged anyone to confuse the language with its implementation.
|
Previous Message
Up
