29401 2016-01-29 00:04:02 +0000 [QT3] numeric-unary return type 2016-03-04 10:14:08 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Linux RESOLVED FIXED P2 normal --- 1 benito oneil abel.braaksma andrew_coleman mike public-qt-comments oldest_to_newest 124734 0 benito 2016-01-29 00:04:02 +0000 Seems no one is looking at #23229 anymore The QT3 also has the tests op-numeric-unary-minus-1 and op-numeric-unary-plus-1 that do not allow xs:integer where a xs:decimal is expected. 124751 1 abel.braaksma 2016-01-30 02:30:58 +0000 I don't think these tests are wrong, according to B.2 Operator Mapping, if the operands are of the same type (where type is xs:integer, xs:decimal, xs:float, xs:double, in that order), the result type after the calculation is applied must also be of that same type. For this test, I believe the only possible outcome is "integer decimal float double double". What other outcome do you suggest is also valid and why? 124761 2 benito 2016-01-30 10:03:13 +0000 Since integer is a subtype of decimal, every integer has the type decimal. So everywhere where a decimal occurs, you can just put an integer. (It could be used as optimization if there is a faster evaluation path for integers) 124763 3 abel.braaksma 2016-01-30 21:35:55 +0000 > Since integer is a subtype of decimal, every integer has the type decimal I agree, but I'm not sure how that influences the result in this test, I'm afraid I'm missing the point here. 124771 4 mike 2016-01-31 16:52:30 +0000 Abel, the point is that if $X is a decimal, then we require that -$X and +$X return a decimal, but this does not preclude them returning an integer, because an integer is a decimal and therefore satisfies the requirement. But the test is written to fail if the returned value is an integer. I have committed a change to the test to use xs:decimal(2.5) rather than xs:decimal(2) so that the question does not arise. Leaving the bug open in case others disagree. 125359 5 oneil 2016-03-04 10:14:08 +0000 I am marking this bug as resolved as we have reached our resolution