I implemented the sch:rule-set element in SchXslt Redaux XSLT1 and XSLT2, assuming that the corresponding SVRL element is called svrl:active-rule-set.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

it is a source of bugs and confusion for schema authors, being at odds with the behaviour of successive assert/report constraints within a rule

True enough. I think the reason for this is that one has to grok that

DECLARATION ORDER DOES NOT DETERMINE RULE EVALUATION ORDER JUST THE SET TO BE EVALUATED

Meaning: If there are two rules A and B where B comes lexically after A, then the if-then-else behavior is a way to state that the assertions of B are checked for nodes selected by B's @context expression but not A's. If there is a third rule C, then the assertions of C are checked for nodes selected by it's @context expresson bot not A's and not B's and so on.

Maybe it's better to thing of rules being exclusive (order is significant) or inclusive (order is not significant)?

Not sure if this should change, tough. In SchXslt I emmit a svrl:shadowed-rule information item to help schema authors.

from schematron-enhancement-proposals.

Would be better to clarify the text, rather than just remove it?

I didn't propose removing it; I proposed providing the option to switch this behaviour off. @rjelliffe 's response seems to be objecting quite forcefully to the proposal on the basis that I would have this removed from the standard, which is not the case.

What confuses people IMHX is that if they come from CAM etc, they expect rules to be independent (ie to be patterns). This is not confusion but innocent ignorance, not a "fault" of Schematron but something to be explained.

I don't know what CAM is, but I disagree. I have not encountered any schema author (I think) who hasn't been tripped up by this. In an imperfect world of non-programmers and non-IT graduates, people want things to operate in the way they reasonably expect them to, with as few surprises as possible. I estimate (completely subjectively) that this feature of Schematron produces more gotchas than any other. @rjelliffe calls it the "The Most Common Programming Error With Schematron". It's a common enough issue to warrant some remedy, and this would be an unintrusive one.

So it is no surprise if now it turns out that the semiformal language is less satisfactory. I still believe the semantics would be better expressed more formally in some logic.

I don't object to the explanation of it; I find that clear. Explaining it differently won't change anything. I and many other users don't find the behaviour intuitive and that is what my proposal seeks to address.

So I think I don't understand Andrew's comment [...]

I think the salient bit is: "So the utility of grouping related rules under a pattern is degraded by an aspect of the implementation."
Patterns are a good thing and so are rules. But you have to do more head-scratching than is really necessary - and schema authors often have real-world deadlines and mission-critical data quality levels to meet - when a rule isn't firing that you expected to. Let an arcane part of the tech get out of the way so we can be as productive as possible.
If you wanted to code defensively and avoid this issue completely, you would put every rule inside its own pattern -- which kind of defeats the point of having patterns in the first place.

That is simply not Schematron.

How gnomic. Is Schematron also an unchanging and unchangeable thing?

If Schematron is "a rule-based validation language for making assertions about the presence or absence of patterns in XML trees" - an admirably clear and simple statement - then it would be best to keep to this level of simplicity and clarity as far as possible.

Since the case can never occur, what is the problem?

The closest analogy I can think of from programming is error hiding, which is generally frowned upon as bad practice.

I think the discussion of the (lexical, logical) order of evaluation and how this is implemented is interesting, but immaterial to this proposal.

@dmj

In SchXslt I emmit a svrl:shadowed-rule information item to help schema authors.

This is a great feature.
I know that I can slow down by releasing the accelerator pedal, but I also like the security of having the brake ;)

from schematron-enhancement-proposals.

I amended the description to make it clearer that this is intended to be a new and backward-compatible option.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

Some implementer notes, if you like.

'and' as a global option

Using templat modes: Create one mode per rule instead one mode per pattern

Using next-match: Modify (remove) the code that tracks which pattern has matched a node.

Using accumulators: Create one accumulator per rule instead one accumulator per pattern.

'and' at the pattern level

Using templat modes: Create one mode per rule of a pattern that uses 'and', create one mode per pattern that uses 'xor'.

Using next-match: Modify (remove) the code that tracks which pattern has matched a node.

Using accumulators: Create one accumulator per rule of a pattern that uses 'and', create one accumulator per pattern that uses 'xor'.

Freely cominbing 'and' and 'xor'

No idea other then fall back to 'ex-post rule match selection': I.e. run like global 'and', post-process the validation report.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

You are right, my mistake.

from schematron-enhancement-proposals.

Hi,

just run into this ticket by accident. I wrote years ago an extension for my Schematron implementation addressing this issue.

I'm also Schematron trainer since years and I can ensure you: this is in practise a really heavy trap of Schematron. In my trainings I saw lot of pale faces after I explained the logic, because they realized that they have to re-check all there patterns they wrote before. And yes, my advice to beginners is: put each rule into an own pattern. But this has also bad side effects! Just to remind you, that for phases you have to activate each pattern by an own <sch:active> element. So this strategy can ends up in a nightmare of maintenance if you have lot of rules and phases.

My proposal would be to make the extension as compact as possible. Reason: I expect that this will be the common way of writting Schematron in future. So make it as simple as possible. For instance an additional attribute on the sch:pattern element (like I proposed it in my extension) and/or better on the sch:schema. Another idea would be to introduce a new grouping element to make the distinction more clear:

<sch:schema>

   <sch:pattern>
       <sch:rule context="old-matching-logic">
   </sch:pattern>

   <sch:group>
       <sch:rule context="new-matching-logic">
   </sch:group>

</sch:schema>

Best Regards,
Nico

from schematron-enhancement-proposals.

Thank you, @nkutsche .

So it does seem that this is a real enough problem for implementers to have proposed solutions.
That alone should not guide us, of course - and an implementation is not necessary for a proposal to be considered here - but I would favour Nico's attribute (or my approach) here, on the grounds that it would be (I say again) 100% backward-compatible.

If there is a need for this, which appears to be the case, then keeping it only implementation-defined means you would get different results for the same schema, based on whether the "do if-then-else processing of rules" flag of your chosen processor were on or off. That feels interesting, but also wrong - in part because it would presumably apply to the schema as a whole, with no granular control over individual patterns.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

@rjelliffe I understand and respect your viewpoint.

I'm not sure though why you refer to this proposal as "getting rid" of first-matching-rule-fires, when I have said above:

For backward compatibility, I propose the current behaviour is retained by default
[...]
this is intended to be a new and backward-compatible option
[...]
it would be (I say again) 100% backward-compatible

Getting rid of something implies to me that it would be irretrievably removed, and that is not the case, as I've mentioned three times. The current behaviour would be the default, and the proposed behaviour an option.

P.S. something is still removing markup and substituting ***@***.*** in your examples.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

@AndrewSales to draft schema change to add sch:rule-set and definition of same.

from schematron-enhancement-proposals.

I've done the same for XQS (for dynamically-evaluated schemas only at this stage), see https://github.com/AndrewSales/XQS/tree/%234.

from schematron-enhancement-proposals.

The proposed name rule-set and associated semantic collide with the proposal in #39, where it would serve to contain abstract rules and patterns. rule-set[@abstract='true'] could mean either a library of abstract rules or the equivalent to pattern[@abstract='true'], but without if-then-else behaviour.

I'm therefore inclining towards group for this issue and rules for the library container - cf. #3.

See Schematron/schema@58c1549 for details.

from schematron-enhancement-proposals.