Saxon

Fixed on the 9.7 branch by widening the signature to accept any numeric operands. This isn't quite what the spec says, but at least any call that conforms to the specified interface will now work correctly.

Reopening this. I don't think it's adequate to fix this by changing the implementation of saxon:decimal-divide. It's broken because the underlying mechanism is broken, and we should fix that. When a method is declared to expect ZeroOrOne, then calling it with an integer should work.

The ideal fix would be align the Java class hierarchy more closely with the XPath type hierarchy: rename the current DecimalValue as BigDecimalValue, and have IntegerValue and BigDecimalValue both be subclasses of an abstract class DecimalValue. That change feels too disruptive for a 9.7 patch, though it might be worth considering for 9.8.

For 9.7 the best approach seems to be that the PJConverter classes ToOne, ToOneOrMore, ToZeroOrOne, and ToZeroOrMore should convert any IntegerValue instances in the input sequence to DecimalValue instances. The tricky thing is how to achieve this without imposing a cost on all uses of these converters.

For 9.7 I have fixed this by ensuring that the PJConverter classes ToZeroOrOne, etc, convert IntegerValue values to DecimalValue when that is the required type.

For 9.8 I have changed the Java class hierarchy to reflect the XDM type hierarchy more closely. The old DecimalValue is renamed BigDecimalValue, and a new DecimalValue is introduced as an abstract class with BigDecimalValue and IntegerValue as subclasses.

Re-opened; the patch causes a crash in XSLT3 test evaluate-008.

Revisions to patch for 9.7 committed.