Saxon

The le operator (a "Value Comparison") always treats an xs:untypedAtomic value as a string. If you want it converted to the type of the other operand, you should use the <= operator (a "General Comparison") which in XSLT must be written in escaped form as <=.

Alternatively, you can do the conversion "by hand", by changing the expression to xs:date($v1) le xs:date($v2).

Hello.

I had a similar problem. When I use saxon9-he (version 9.8.0.6) for XPath in an application on Net Framwork, there is an error "net.sf.saxon.trans.XPathException: Can not compare xs: untypedAtomic to xs: decimal".

This occurs when XPathSelector evaluates an expression using the "Evaluate" method. The expression itself looks like this: matches ($ var1 / text (), '^ [0-9] {1,2} . [0-9] {2} $') or ($ var1 eq 100.0).

Variable "var1" is set in XPathSelector by the SetVariable method as XdmNode. The variant of changing the expression is strongly undesirable.

I ask you to suggest a possible way out of this situation.

Same problem, and same solution...

The "=" operator implicitly converts xs:untypedAtomic values to the type of the other operand; the "eq" operator does not.

The reason for this was to give "eq" clean transitive semantics which is needed for building indexes.

I suggest you stick with "eq", but do the conversion explicitly:

xs:decimal($var1) eq 100.0

or use "=" if you prefer:

$var1 = 100.0

Michael.

Thank you for the detailed response. This helped solve the problem for this case. However, is there really no technical possibility at the Saxon Api level to perform an explicit transformation of the "TypedValue" (xs: untypedAtomic) type "XdmNode" to "DecimalAtomicValue" (as in my example)?

However, is there really no technical possibility at the Saxon Api level to perform an explicit transformation of the "TypedValue" (xs: untypedAtomic) type "XdmNode" to "DecimalAtomicValue" (as in my example)?

There are variious ways you could do this at the Java level. For example

new XdmAtomicValue(xdmNode.getStringValue(), ItemType.DECIMAL);

We've avoided representing all the built-in atomic types as subtypes of XdmAtomicValue, to avoid proliferation of classes, and because on the whole we don't want to encourage people to do things in Java that could be done in XPath/XSLT/XQuery.

Now it is clear. Thanks for the answer/