search

FontoXML / fontoxpath

A minimalistic XPath 3.1 implementation in pure JavaScript
MIT License
135 stars 17 forks source link

Order of XPath returns different results when comparing untypedAtomic to date. #109

Closed ymor closed 5 years ago

ymor commented 5 years ago

Working example: https://xpath.playground.fontoxml.com/?mode=0&variables=%7B%7D&xml=+%3C%21--Update+to+actual+current+date+--%3E%0A%3CcurrentDate%3E2019-05-01%3C%2FcurrentDate%3E&xpath=+current-date%28%29+%3D+%2FcurrentDate%0A

Not working example: https://xpath.playground.fontoxml.com/?mode=0&variables=%7B%7D&xml=+%3C%21--Update+to+actual+current+date+--%3E%0A%3CcurrentDate%3E2019-05-01%3C%2FcurrentDate%3E&xpath=%2FcurrentDate+%3D+current-date%28%29

DrRataplan commented 5 years ago

Nice find! I think something may go awry with the atomization step that runs before the comparison. I'll look into this next Friday!

DrRataplan commented 5 years ago

I see the problem(s):

We have a bug in generalCompare, the typecasting of xs:untypedAtomics is wrong. In essence, if one of the operands is an untypedAtomic, the other one is made one too, resulting in two untypedAtomics. This is wrong. See https://www.w3.org/TR/xpath-31/#doc-xpath31-GeneralComp, 2.b.iv.

This fault causes us to cast both operands to xs:untypedAtomics, stringifying them. The stringification causes the timezone to be added to the result of the current-date() function. this makes them unequal.

I believe that the timezone part is the correct behaviour (https://www.w3.org/TR/xpath-functions-31/#func-current-date).

DrRataplan commented 5 years ago

Thanks for filing this issue! I just merged it and this will be released with the next release, probably somewhere this week.