Saxon

When I execute the XPath query count(//parent::node()) directly against your source document, I get the answer 379, which is what you appear to be expecting.

If schematron is getting a different answer, then that must be because it is doing something different. I'm afraid we can't debug schematron code for you. You haven't even told us which schematron processor you are using. Is it one that generates XSLT? If you can send us the XSLT and convince us that a known XSLT stylesheet is not producing the correct output, then that's something we can investigate.

Have you checked any variations on the expression such as number($cnt2) eq 379 or $cnt = 379 or $cnt = '379'? One possible explanation, if $cnt displays as "379" but doesn't compare "eq" to 379, is that it's a string rather than a number. Without knowing schematron, I've no idea if that's a real possibility.

I have generated the XSLT stylesheet using the "skeleton" schematron implementation and am running the XSLT directly against the source document, which demonstrates that this does appear to be a Saxon problem. The XPath expression count(//parent::node()) is evaluated successfully, but there seems to be a problem with the variable $cnt2. Adding xsl:message output to show the variable value causes everything to run fine; this is usually an indication of some incorrect optimisation rewrite, which doesn't happen when an extra reference to the variable is added.

In the absence of a second reference to the variable, the variable has been inlined, giving an expression like

if test="count(//parent::node()) = 379" then () else <svrl:failed-assert..../>

This then triggers another optimization, where count(X) = N is replaced by count(subsequence(X, 1, N+1)) = N. The idea of this optimization is to avoid evaluating more items in the expression than are needed to establish whether or not the sequence size is 379.

The debugger shows that the actual length of the subsequence() is 380.

It looks to me as if the expression isn't eliminating duplicates. Clearly the naive nested-loop evaluation strategy for a descendant/parent path expression is going to include duplicates that need to be eliminated, but there doesn't appear to be any code on the expression tree to do this.

ValueComparison.optimizeCount() is responsible for the rewrite of the count(X) = N expression, and it starts by doing

sequence = sequence.unordered(false, false);

which is done to avoid unnecessary sorting of the input sequence (the order of the sequence does not affect its size). The first argument to this call is a flag retainAllNodes which should be set to true, indicating that although the order of the sequence does not matter, the presence or absence of duplicates does.

Setting this argument to true appears to solve the problem.

Incidentally, a more efficient query to count the number of nodes that have children is probably

count(//node()[child::node()])

Writing it this way doesn't involve any sorting or elimination of duplicates.

Thanks so much! Is there a plan for a new maintenance release in the near-term?

We base the decision on the number of outstanding patches and their severity. There are currently 12 outstanding patches for 9.9 and the rate has slowed to about 6 a month, so I think it's likely to be 4-6 weeks before we decide another maintenance release is due. Suggest you try the workaround in comment #6 - which is a better way to write the query anyway.