* ArrayTest-012, ArrayTest-013, ArrayTest-014, ArrayTest-024, ArrayTest-026
  Result: XPDY0138, XPTY0004
  Expecting FOAY0001

* xs-numeric-021, xs-numeric-022
  Schema dependency is missing:
  <dependency type="feature" value="schemaImport"/>

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.

Note re comment 2, the actual dependency is on SchemaValidation, not SchemaImport.

> 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"/>

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.

Test cases fixed according comment #5

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.

Correction made according to comment 8

(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.

(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.

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"?

(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.

> 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

(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.

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.

(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.

Bug fix applied to the test cases cbcl-castable-long-001, cbcl-castable-long-002, cbcl-castable-unsignedLong-001 as suggested

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

Fixed by myself.