27180 2014-10-27 20:11:13 +0000 Various minor bugs and inconsistencies 2015-07-13 20:32:44 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Working drafts PC Windows NT RESOLVED FIXED P2 normal --- 28944 1 christian.gruen oneil botond23 mike tim public-qt-comments oldest_to_newest 113799 0 christian.gruen 2014-10-27 20:11:13 +0000 * fn-data-7 Result: FOTY0012 Expecting FOTY0013 → The argument to fn:data() contains a function item. * K-ErrorFunc-4, XPTY0004_12 Result: XPTY0004 Since XQuery 3.1: FOER0000 (single argument of fn:error can be empty sequence) * K-TokenizeFunc-1 Result: XPST0017 Since XQuery 3.1: tokenize() also accepts a single argument * K-TraceFunc-2 Result: XPST0017 Since XQuery 3.1: trace() also accepts a single argument * map-size-007, map-keys-007, map-for-each-007 Expecting XQDY0137 (key was defined more than once) * cbcl-castable-long-001, cbcl-castable-long-002, cbcl-castable-unsignedLong-001 Expecting FOAR0002 (Overflow/underflow; additionally to existing result) * UCA-collation-009 (...hiraganaQuaternary=unknown) Note: may need to be removed (see bug 27178) * UCA-collation-022 (...version=7.0) Result: FOCH0002 Expecting no error, as version 7.0 is already published * The following test have "XQ30" as dependency. It should probably be "XQ30+": K2-DirectConElem-53a K-FunctionCallExpr-15a K-InternalVariablesWith-16a K-InternalVariablesWith-17a K-InternalVariablesWith-18a K-InternalVariablesWith-19a K-InternalVariablesWith-20a K2-VersionProlog-3-v3 version_declaration-022-v3 VersionDecl-v3-processor-and-v1-query version_declaration-010-v3 K-VersionProlog-3-v3 K-VersionProlog-4-v3 K-VersionProlog-2-v3 prolog-version-4-v3 prolog-version-5-v3 prolog-version-6-v3 prolog-version-7-v3 prolog-version-1-v3 prolog-version-3-v3 K-VersionProlog-5-v3 116265 1 christian.gruen 2014-12-13 17:43:32 +0000 * ArrayTest-012, ArrayTest-013, ArrayTest-014, ArrayTest-024, ArrayTest-026 Result: XPDY0138, XPTY0004 Expecting FOAY0001 116266 2 christian.gruen 2014-12-13 18:32:45 +0000 * xs-numeric-021, xs-numeric-022 Schema dependency is missing: <dependency type="feature" value="schemaImport"/> 116276 3 mike 2014-12-14 09:12:38 +0000 Re comment 1, the WG made a decision to unify the error code for "array index out of bounds", though I don't see that implemented yet in the spec. Re comment 2, we assume an implicit dependency on schema-awareness if the environment uses a schema, but I can't see anything in the test suite documentation to justify that, so I'll make it explicit. Generally, please try to avoid portmanteau bugs. It makes it harder to track the problems to a resolution. We don't count the number of bugs, and integers are not a scarce resource. 116277 4 mike 2014-12-14 09:23:21 +0000 Note re comment 2, the actual dependency is on SchemaValidation, not SchemaImport. 116278 5 christian.gruen 2014-12-14 12:13:47 +0000 > Generally, please try to avoid portmanteau bugs. It makes it harder to track the problems to a resolution. We don't count the number of bugs, and integers are not a scarce resource. ;) Thanks for the advice, Michael (I didn't expect any discussion to evolve on the issues at all). Is it ok to create one entry for all those minor observations, or would you prefer to have many small bug entries? I have enumerated the existing entries below: 1. fn-data-7 Result: FOTY0012 Expecting FOTY0013 → The argument to fn:data() contains a function item. 2. K-ErrorFunc-4, XPTY0004_12 Result: XPTY0004 Since XQuery 3.1: FOER0000 (single argument of fn:error can be empty sequence) 3. K-TokenizeFunc-1 Result: XPST0017 Since XQuery 3.1: tokenize() also accepts a single argument 4. K-TraceFunc-2 Result: XPST0017 Since XQuery 3.1: trace() also accepts a single argument 5. map-size-007, map-keys-007, map-for-each-007 Expecting XQDY0137 (key was defined more than once) 6. cbcl-castable-long-001, cbcl-castable-long-002, cbcl-castable-unsignedLong-001 Expecting FOAR0002 (Overflow/underflow; additionally to existing result) 7. UCA-collation-009 (...hiraganaQuaternary=unknown) Note: may need to be removed (see bug 27178) 8. UCA-collation-022 (...version=7.0) Result: FOCH0002 Expecting no error, as version 7.0 is already published 9. The following test have "XQ30" as dependency. It should probably be "XQ30+": K2-DirectConElem-53a K-FunctionCallExpr-15a K-InternalVariablesWith-16a K-InternalVariablesWith-17a K-InternalVariablesWith-18a K-InternalVariablesWith-19a K-InternalVariablesWith-20a K2-VersionProlog-3-v3 version_declaration-022-v3 VersionDecl-v3-processor-and-v1-query version_declaration-010-v3 K-VersionProlog-3-v3 K-VersionProlog-4-v3 K-VersionProlog-2-v3 prolog-version-4-v3 prolog-version-5-v3 prolog-version-6-v3 prolog-version-7-v3 prolog-version-1-v3 prolog-version-3-v3 K-VersionProlog-5-v3 comment 1: 10. ArrayTest-012, ArrayTest-013, ArrayTest-014, ArrayTest-024, ArrayTest-026 Result: XPDY0138, XPTY0004 Expecting FOAY0001 comment 2: 11. xs-numeric-021, xs-numeric-022 Schema dependency is missing: <dependency type="feature" value="schemaImport"/> 116281 6 mike 2014-12-14 21:28:54 +0000 Even when there's no discussion needed, different problems might be clsoed at different times. If it's the same problem in a group of related tests, that are likely to be fixed by the same person at the same time, feel free to use a single bug. For unrelated problems in unrelated tests, it's better to raise multiple bugs, so they can be assigned to different people and closed at different times. 116376 7 oneil 2014-12-16 13:07:33 +0000 Test cases fixed according comment #5 116495 8 tim 2014-12-18 15:34:41 +0000 The change requested to tests cbcl-castable-long-001, cbcl-castable-long-002, and cbcl-castable-unsignedLong-001 was to add an additional error code. However, O'Neil appears to have replaced FORG0001 with FOAR0002. Please correct. 116526 9 oneil 2014-12-18 23:00:16 +0000 Correction made according to comment 8 116548 10 botond23 2014-12-19 09:29:56 +0000 (In reply to O'Neil Delpratt from comment #9) > Correction made according to comment 8 I think for the testcases cbcl-castable-long-001, cbcl-castable-long-002, cbcl-castable-unsignedLong-001 the changes were incorrect - the expected result should be assert-false and not the overflow error. In my understanding, the castable as expressions should not fail if the lhs expression was evaluated successfully. 116549 11 tim 2014-12-19 09:38:55 +0000 (In reply to Botond Biró from comment #10) > (In reply to O'Neil Delpratt from comment #9) > > Correction made according to comment 8 > > I think for the testcases cbcl-castable-long-001, cbcl-castable-long-002, > cbcl-castable-unsignedLong-001 the changes were incorrect - the expected > result should be assert-false and not the overflow error. > In my understanding, the castable as expressions should not fail if the lhs > expression was evaluated successfully. I agree. Prior to the change, the test expected only false. 116554 12 christian.gruen 2014-12-19 13:56:52 +0000 I think this is the correct result for the three cases: <result> <any-of> <assert-false/> <error code="FOAR0002"/> </any-of> </result> Tim wrote in Comment 8: > However, O'Neil appears to have replaced FORG0001 with FOAR0002. Were you supposed to say "assert-false" instead of "FORG0001"? 116555 13 tim 2014-12-19 14:14:34 +0000 (In reply to Christian Gruen from comment #12) > I think this is the correct result for the three cases: > > <result> > <any-of> > <assert-false/> > <error code="FOAR0002"/> > </any-of> > </result> > > Tim wrote in Comment 8: > > > However, O'Neil appears to have replaced FORG0001 with FOAR0002. > > Were you supposed to say "assert-false" instead of "FORG0001"? Yes. FORG0001 is the error cast would raise I'm not entirely certain why you'd expect FOAR0002. If the large integer value is too big for your internal representation of a decimal value, I'd have expected you to raise FOCA0001, but it's probably arguable. 116558 14 christian.gruen 2014-12-19 15:30:46 +0000 > I'm not entirely certain why you'd expect FOAR0002. If the large integer value > is too big for your internal representation of a decimal value, I'd have > expected you to raise FOCA0001, but it's probably arguable. As the description for FOCA0001 is "Input value too large for decimal.", I am not sure if this would be the best choice, as the input is an integer (we have no problem to represent larger decimals). We chose FOAR0002 based on the interpretation of the spec shown below. Maybe a parse error (XQST) could be more appropriate, but in practice, it has not been an issue so far: * [1] "The value of a numeric literal containing no "." and no e or E character is an atomic value of type xs:integer. [...] The value of the numeric literal is determined by casting it to the appropriate type according to the rules for casting from xs:untypedAtomic to a numeric type as specified in Section 19.2 Casting from xs:string and xs:untypedAtomic FO31." * [2] "If the value is too large or too small to be accurately represented by the implementation, it is handled as an overflow or underflow as defined in 4.2 Arithmetic operators on numeric values." * [3] "For xs:integer operations, implementations that support limited-precision integer operations ·must· select from the following options: They ·may· choose to always raise a dynamic error [err:FOAR0002]." [1] http://www.w3.org/TR/xquery-31/#id-literals [2] http://www.w3.org/TR/xpath-functions-31/#casting-from-strings [3] http://www.w3.org/TR/xpath-functions-31/#op.numeric 116562 15 mike 2014-12-19 17:15:42 +0000 (In reply to Christian Gruen from comment #14) I agree with Christian's reading of the spec here. I think the only legitimate outcomes are false (if the implementation can handle integers this large), and FOAR0002 (if it can't). For the second case, the failure occurs when constructing the integer literal, which uses the rules for casting string to integer; the failure is while evaluating the lhs of the "castable" expression, and such a failure throws the error rather than returning false. 116594 16 mike 2014-12-19 23:40:41 +0000 Another comment here, it's a wrong approach to read the list of error codes and see which one has the best-fit description. The descriptions are often hopelessly generic (e.g. err:FORG0006, Invalid argument type.). You have to work from the rules for the construct in question. Here I started with the rules in the XPath/XQuery book for numeric literals, which takes you to F+O 19.1.2.4 (casting to xs:integer) which takes you to 19.2 (casting from xs:string), which takes you to If the value is too large or too small to be accurately represented by the implementation, it is handled as an overflow or underflow as defined in 4.2 Arithmetic operators on numeric values. and 4.2 has For xs:integer operations, implementations that support limited-precision integer operations ·must· select from the following options: They ·may· choose to always raise a dynamic error [err:FOAR0002]. They ·may· provide an ·implementation-defined· mechanism that allows users to choose between raising an error and returning a result that is modulo the largest representable integer value. See [ISO 10967]. An implementor who wants to take the second option could challenge the test on those grounds (it would give a result of "true"!), but no-one has done so; the only other option, if you don't support an integer of this size, seems to be FOAR0002. 116641 17 oneil 2014-12-22 11:03:04 +0000 (In reply to Christian Gruen from comment #12) > I think this is the correct result for the three cases: > > <result> > <any-of> > <assert-false/> > <error code="FOAR0002"/> > </any-of> > </result> > If there are no objections I think I will follow what is said in comment #12 as the expected result. From the reasoning of Mike's comment #15 and #16 I did follow it through in the spec and I agree it seems to me the correct resolution to this bug. 116643 18 oneil 2014-12-22 15:42:38 +0000 Bug fix applied to the test cases cbcl-castable-long-001, cbcl-castable-long-002, cbcl-castable-unsignedLong-001 as suggested 117297 19 christian.gruen 2015-01-18 10:43:34 +0000 I have reopened this bug report due to a minor issue: in XPTY0004_12 and XPTY0004_12a, the dependencies were not added yet: <dependency type="spec" value="XQ10 XP20 XQ30 XP30" /> <dependency type="spec" value="XQ31+ XP31+" /> This is the original commit: https://github.com/LeoWoerteler/QT3TS/commit/eb79da906c8875de97245a27cb7c44a5918dfc72#diff-25b65cb2a523b0b6045d4fd2020efe13L1451 117303 20 christian.gruen 2015-01-19 09:23:12 +0000 Fixed by myself.