Allow <rule> elements without contents

[xatapult]

According to the official Schematron schema, an empty <rule> (not containing asserts/reports) is not allowed. However, there are use-case where this is useful. For instance, when you purposely want to stop further validation in a pattern when a certain condition is true.

Therefore I would propose to allow empty <rule> elements as well.

[rjelliffe]

It would be good to have a specific use case.

I can think of five scenarios, each with different solutions:

1. We only want to test certain rules, as a matter of modeled progressive validation. In other words, it fits into Schematron's model as an enhancement of the phase mechanism. (In which case, say, we could introduce sch:phase/sch:active/@before which takes an IDREF to a sch:rule in that pattern, so that in that phase only the rules before the rule with that ID are tested.)

2. We want to have a simple kind of exclusion. But we can do this already, for example:

...

This pattern is not applicable to tables. ... The use of true() means the assertion will never be reported, but we still have assertion text that clearly states what the intention is. No subsequent rules will be tested, as we have a match. I think this is the case Erik is interested in: but I think the issue is not "I want a rule that matches with no assertions" but "how can we exclude some contexts." So I think this scenario is adequately handled. (And, of course, a quick and dirty approach for non-schema uses only needs to have to satisfy the need for an explicit assertion.) 3. We want to simplify longer Xpaths by which branches are tested. (In which case, say, we could introduce sch:pattern/@from with an XPath specifying where in the document the pattern rules would be applied.) 4. During testing, we want a quick and dirty way to turn off some rules. One of the benefits of having the sch:title and sch:p elements is that it reduces the need for XML comment tags. Which makes simple commenting-out of unwanted elements a low-complexity option: you have little risk that you will need to cope with nested comments. So I think this scenario is adequately handled. 5. We want more control of what is tested. Some implementations have a fast-terminate command-line option for this, so as soon as an assertion fails, nothing more is tested. But there are lots of other options an implementation could provide: e.g fast fail on a failed assertion with some @role value. Or don't check anything under a failed node, byt do check the rest of the document. An implemenration could provide an option to turn off any rule (i.e., dont test any assertions for that rule if it fires.) Regards Rick On Mon, 16 May 2022, 9:28 pm Erik Siegel, ***@***.***> wrote: > According to the official Schematron schema, an empty (not > containing asserts/reports) is not allowed. However, there are use-case > where this is useful. For instance, when you purposely want to stop further > validation in a pattern when a certain condition is true. > > Therefore I would propose to allow empty elements as well. > > — > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[AndrewSales]

@rjelliffe , here and in some of your other contributions to this repo, something is inserting ***@***.*** in your posts in place of what I assume is markup or an XPath(?), which makes them quite hard to follow. See e.g. (1) and (3) above.

[tgraham-antenna]

@AndrewSales, I blame GitHub for trying to obfuscate email addresses and overreaching. This is an email address: john@example.com. This is an XPath for an attribute: john/@example. This is the XPath as code: john/@example.

---

Or maybe not GitHub. It turns out that I couldn't reproduce the effect.