xerces-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mukul Gandhi <muk...@apache.org>
Subject Re: Xerces-J 2.12.0 vs. Saxon: XSD 1.1 gYearMonth comparison is failing
Date Sat, 11 Aug 2018 10:35:01 GMT
On Fri, Aug 10, 2018 at 9:58 PM, ykhabins <yitzhak.khabinsky@millicom.com>

> It seems like a bug in the *Eclipse/PsychoPath XPath 2.0 engine* that
> Xerces is using.
> https://www.w3.org/TR/xpath-functions-31/#func-gYearMonth-equal
> 19.1 Casting from primitive types to primitive types The w3c spec.
> explicitly shows that xs:date shall convert into xs:gYearMonth
You've pointed to the spec, "XPath and XQuery Functions and Operators 3.1"
with the link above. XSD 1.1 uses XPath 2.0. Therefore the right link
should have been,
This section allows a cast from xs:date to xs:gYearMonth. Therefore you're

Just to try identify the bug, I tested following <assert> XPath expressions
with Xerces XSD 1.1, and the results I got are also mentioned,

<xs:assert test="xs:gYearMonth('2018-07') eq xs:gYearMonth('2018-07')"/>

<xs:assert test="string(xs:gYearMonth(xs:date('2018-07-05'))) eq

<xs:assert test="xs:gYearMonth(xs:date('2018-07-05')) eq

The first two of above <assert>'s gave a true result. The third one gives a
false result (this looks like a bug). We also need to revisit XPath 2.0
atomization in this area I think.

The XPath 2.0 processor that Xerces uses, is from Eclipse WTP Source
Editing project. Earlier we used to have commit rights on the Eclipse WTP
Source Editing project. But currently we don't have commit rights on that
project. Therefore as of now, we're not in position to fix any XPath 2.0
bugs identified after Xerces 2.12.0 release. I apologize, if you find this
current situation inconvenient.

Mukul Gandhi

View raw message