Open PStellmann opened 7 years ago
In Schematron, I decided againt putting in a special class of guard paths, because guards usually hide assertions. Similarly, I didn't want to support arbitrary composition of assertions (i.e. using and/or or case statements instead of rules) in order to encourage/enforce a flat structure of simple statements.
So, without claiming this is good enough for you, the most efficient way of doing guards currently is to use a top-level boolean variable for the guard condition, so you have
...
Thanks for your thoughts.
The disadvantage of adding the condition to the patterns is a poor worst-case-behavior: So when there is only a single rule in that pattern still the whole document will be processed.
However, I agree that the @followup on a rule could do the same and is even more powerfull since it is not limits to conditions on document level but can deactive the validation of any subtree.
Just as a comparision of the source-code variants to get a feeling:
<sch:pattern condition="contains(/*/@class, ' custom-domain/myTopic ')">
<sch:rule context="*[contains(@class, ' custom-domain/myElement ')]">
<sch:assert test="...">
<!-- message -->
</sch:assert>
</sch:rule>
</sch:pattern>
<sch:let name="is-not-myTopic" value="not(contains(/*/@class, ' custom-domain/myTopic '))"/>
<sch:pattern>
<sch:rule context="*[$is-not-myTopic]" followup="skip-content">
<!-- no tests, just abort the validation -->
</sch:rule>
<sch:rule context="*[contains(@class, ' custom-domain/myElement ')]">
<sch:assert test="...">
<!-- message -->
</sch:assert>
</sch:rule>
</sch:pattern>
I'm gonna start the implementation of my validation framwork within the next 2-3 weeks using @followup and will post my experience here...
I would like to be able to specify a condition (as xpath to be applied to the input document) to check if a set of patterns should be executed.
I have two use-cases for this, both from a DITA context:
*[contains(@class, ' custom-domain/myElement ')]
. When processing a standard DITA topic that does not use the custom domain this pattern will never match - and I already know this from looking at the root element. One option would be to extend the pattern to/*[contains(@class, ' custom-domain/myTopic ')]//*[contains(@class, ' custom-domain/myElement ')]
. But the resulting xsl:template will still be checked for every single node. So adding some condition to the pattern-element (or preferably a set of patterns) could skip the whole traversal for all files not fulfilling this condition.