On Fri, Aug 10, 2018 at 9:58 PM, ykhabins <yitzhak.khabin...@millicom.com> wrote:
> 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, https://www.w3.org/TR/xquery-operators/#casting-from-primitive-to-primitive. This section allows a cast from xs:date to xs:gYearMonth. Therefore you're right. 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 '2018-07'"/> <xs:assert test="xs:gYearMonth(xs:date('2018-07-05')) eq xs:gYearMonth('2018-07')"/> 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. -- Regards, Mukul Gandhi
