Saxon

Thanks for your response. I have just tried it on the latest (9.6.0-6) release but unfortunately still get the same error. This is how I am running the expression (I have just translated this from scala code, sorry if some errors have crept in):

Boolean licensedEdition = true;
Processor processor = new Processor(licensedEdition);
SchemaManager sm = processor.getSchemaManager();
//Load the xsd serialized as a string
sm.load(new StreamSource(new StringReader(xsd.toString())));
SchemaValidator sv = sm.newSchemaValidator();
XdmDestination xdmDest = new XdmDestination();
sv.setDestination(xdmDest);
//Load the instance serialized as a string
sv.validate(new StreamSource(new StringReader(xml.toString())));
String xpathExpr = "//test:comparable[1]/test:int eq //test:comparable[2]/test:int";
XPathCompiler comp = processor.newXPathCompiler();
comp.declareNamespace("test", "http://www.xpathtest.com/test");
XPathExecutable xpathExec = comp.compile(xpathExpr);
XPathSelector selector = xpathExec.load();
selector.setContextItem(xdmDest.getXdmNode());
Boolean result = selector.effectiveBooleanValue();

OK, the problem is that the XPathCompiler has not been declared schema-aware - you need to call compiler.setSchemaAware(true).

The expression has been compiled in non-schema-aware mode, which means that the code that's generated assumes that the operands to the value comparison will be strings; it tries to cast them to strings, gets a ClassCastException, and this results in the strange message.

There's a good reason why the default is NOT schema aware, which is that in the common case where documents are untyped, you can generate faster code if you know in advance that they will be untyped; generating schema-aware code for a case where it's not needed would incur unnecessary costs. (Conversely, of course, if the document is going to be schema-validated then it's useful to know that, as well).

Of course, what's wrong here is the diagnostics. If you've compiled the code without schema-awareness enabled, then Saxon ought to complain very clearly when you supply a schema-validated input document. I'll now look at what I can do to fix that.

The problem is specific to the XPath API; at this level, XSLT and XQuery behave differently.

Thanks very much for your quick analysis and solution! Making the XPathCompiler schema aware indeed solves the problem. And the improved error message will certainly help diagnosing this problem in the future.