Additional information: there are 74 total test cases inside the 'math' test sets that should be corrected.

And there are 48 test cases part of the test sets from 'fn' folder.

Here are 2 more examples of misuse of the 'assert-eq':

1) "op-numeric-add" test set, "op-numeric-addflt2args-3" test case:

<test-case name="op-numeric-addflt2args-3">
  <description> Evaluates The "op:numeric-add" operator with the arguments set as follows: $arg1 = xs:float(lower bound) $arg2 = xs:float(mid range) </description>
  <created by="Carmelo Montanez" on="2004-12-13"/>
  <test>xs:float("-3.4028235E38") + xs:float("0")</test>
  <result>
    <assert-eq>xs:float(-3.4028235E38)</assert-eq>
  </result>
</test-case>

Instead of :
<test-case name="op-numeric-addflt2args-3">
[...]
  <result>
   <assert>$result eq xs:float(-3.4028235E38)</assert>
  </result>
</test-case>

2)test set "op-numeric-divide", test case "op-numeric-dividesht2args-5":

<test-case name="op-numeric-dividesht2args-5">
 <description> Evaluates The "op:numeric-divide" operator with the arguments set as follows: $arg1 = xs:short(lower bound) $arg2 = xs:short(upper bound) </description>
 <created by="Carmelo Montanez" on="2004-12-13"/>
 <test>xs:short("-32768") div xs:short("32767")</test>
 <result>
   <any-of>
     <assert-eq>-1.000030518509475997</assert-eq>
     <assert-eq>-1.000030518509475997192297128208258</assert-eq>
     <assert-eq>-1.000030518509</assert-eq>
   </any-of>
 </result>
</test-case>

What if the XQuery processor returns '-1.0000305185094759972' ?

<test-case name="fn-abs-1">
 <description>numeric types. Author: Oliver Hallam Date: 2010-03-15</description>
 <created by="Oliver Hallam" on="2010-03-15"/>
 <environment ref="empty"/>
 <test>string-join(for $x in (1, xs:decimal(2), xs:float(3), xs:double(4)) return 
           if ((abs($x)) instance of xs:integer) then "integer" 
           else if ((abs($x)) instance of xs:decimal) then "decimal" 
           else if ((abs($x)) instance of xs:float) then "float"
           else if ((abs($x)) instance of xs:double) then "double" else error(), " ")</test>
 <result>
  <assert-eq>"integer decimal float double"</assert-eq>
 </result>
</test-case>

instead of:
<test-case name="fn-abs-1">
[...]
 <result>
  <assert>$result eq "integer decimal float double"</assert>
 </result>
</test-case>

1. If you have enumerated all the affected tests then it would be helpful to supply the list. It would be even better to supply a shorter list where the changes are essential, since resources are limited.

2. I don't understand comment #4. What's wrong with the test as written, and how does it relate to this bug report?

(In reply to comment #5)
> 1. If you have enumerated all the affected tests then it would be helpful to
> supply the list. It would be even better to supply a shorter list where the
> changes are essential, since resources are limited.
> 
> 2. I don't understand comment #4. What's wrong with the test as written, and
> how does it relate to this bug report?
Let me try to answer both issues in the same time because they are connected:
I implemented the function for checking the "assert-eq" into a FOTS driver.
I run all the tests in the FOTS that have this assertion defined and I analysed the failures.

I did not find any way of implementing an "assert-eq" check that is able to account for all the misuses of this assertion into the FOTS.

1) if I make the assumption that the "assert-eq" was created to compare the string values of the actual and expected results, than a bunch of tests fail.

Here are some examples:
<result><assert-eq>1.5707963267948966e0</assert-eq></result> compared to an actual result of 1.5707963267948966
<result><assert-eq>0e0</assert-eq></result> compared to an actual result of 0
<result>"X"</assert-eq></result> compared to an actual result X (because of the additional commas in the expected result)

2) if I make the assumption that the "assert-eq" was created to compare the values of the actual and expected results but only after casting them both to the type of the actual result another set of tests fail.
Some of the above mentioned tests pass, because 
xs:double(1.5707963267948966e0) eq xs:double(1.5707963267948966) and also xs:double (0e0) eq xs:double(0)

IMHO one of the main causes for these confusions (both for those writing tests and for those trying to write drivers that are able to run the tests correctly) is the lack of information in the FOTS catalog for the "assert-eq":

"assert-eq  denotes an element whose assumption when run must equal the expected test result."

IMHO we should give more specific details about how the result and actual results are compared:
- is there any serialization done to the actual result?
- the things that are compared are the string values or should there be some casting done first?

Also some common sense advices would also be very helpful, something like:
- if one is interested in checking the type of the results please consider using "assert-type" instead of "assert-eq"
- if one needs to compare numeric values that have decimals please consider using "assert" instead of "assert-eq".

So here is what I would propose:
- please add the necessary details into he FOTS schema for "assert-eq"
- after I implement the "assert-eq" in the driver it would be very simple for me to provide a verbose list of all tests in the FOTS that misuse "assert-eq" (according to the complete description from the FOTS schema).

Would this work?

>"assert-eq  denotes an element whose assumption when run must equal the
expected test result."

What my copy says is:

"The assert element contains an XPath expression (usually a simple string or numeric literal) which must be equal to the result of the test case under the rules of the XPath 'eq' operator. "

which seems clear enough. Are you using the latest CVS copy?

(In reply to comment #7)
> >"assert-eq  denotes an element whose assumption when run must equal the
> expected test result."
> 
> What my copy says is:
> 
> "The assert element contains an XPath expression (usually a simple string or
> numeric literal) which must be equal to the result of the test case under
> the rules of the XPath 'eq' operator. "
> 
> which seems clear enough. Are you using the latest CVS copy?

I looked at this:
http://dev.w3.org/cvsweb/~checkout~/2011/QT3-test-suite/catalog-schema.html?rev=1.1;content-type=text%2Fhtml#elem_assert-eq

(In reply to comment #8)
> (In reply to comment #7)
> > >"assert-eq  denotes an element whose assumption when run must equal the
> > expected test result."
> > 
> > What my copy says is:
> > 
> > "The assert element contains an XPath expression (usually a simple string or
> > numeric literal) which must be equal to the result of the test case under
> > the rules of the XPath 'eq' operator. "
> > 
> > which seems clear enough. Are you using the latest CVS copy?
> 
> I looked at this:
> http://dev.w3.org/cvsweb/~checkout~/2011/QT3-test-suite/catalog-schema.
> html?rev=1.1;content-type=text%2Fhtml#elem_assert-eq

There are some issues I see:
- the catalog-schema.xsd says what you have, that is true
- the catalog-schema.html says is not updated (so it mentions what I stated)
- the description in the catalog-schema.xsd does not account for the "empty environment" issue I reported in bug 19783: that is the fact that the "assert-eq" is not checked in the same environment defined for the test itself but in a default/empty one (where math prefix is not defined for instance).

"For example, <assert-eq>12&</assert-eq> asserts that the result of the test expression is an atomic value that compares equal to the integer 12 (which means it might be the double value 12.0 or the float value 12.0 or the untyped atomic value "12.0", for example)."

Means that
<assert-eq>"integer decimal float double"</assert-eq>
would not succeed when compared to ('integer', 'decimal', 'float', 'double')
and would succeed when compared to ('"', 'integer', 'decimal', 'float', 'double', '"')
right?

The latest version of the schema can be seen here:

http://dev.w3.org/cvsweb/~checkout~/2011/QT3-test-suite/catalog-schema.xsd?rev=1.25;content-type=application%2Fxml#elem_assert-eq

>Means that
<assert-eq>"integer decimal float double"</assert-eq>
would not succeed when compared to ('integer', 'decimal', 'float', 'double')
and would succeed when compared to ('"', 'integer', 'decimal', 'float',
'double', '"') right?

This test, no doubt for historic reasons, returns a single string, not a sequence of four (or six) strings, and the assertion compares the result by comparing the value of that single string using the "eq" operator.

As discussed, here is the list of test cases that I propose to be investigated:

- "math-acos" test set, "math-acos-003"

- "op-numeric-divide" test set, "op-numeric-dividesht2args-5" -replace alternate results with "assert"

- "prod-CastExpr" test set, "CastFOCA0001-1,CastFOCA0003-1" -replace alternate results with "assert"

- "prod-CastExpr" test set, "K2-SeqExprCast-17" - provide alternate result for <error code="FOAR0002"/>

- "prod-TryCatchExpr" test set "try-catch-optimizations-1" - the result is a sequence of 2 items

Bug fixed and committed to cvs.

(In reply to comment #13)
> - "math-acos" test set, "math-acos-003"

There is also a problem with the test case math-acos-003
Changed the expected result to the following:

<assert>abs($result - 1.5707963267948966e0) lt 1e-14</assert>

> - "op-numeric-divide" test set, "op-numeric-dividesht2args-5" -replace
> alternate results with "assert" 
> - "prod-CastExpr" test set, "CastFOCA0001-1,CastFOCA0003-1" -replace
> alternate results with "assert"
 
DONE

> - "prod-CastExpr" test set, "K2-SeqExprCast-17" - provide alternate result
> for <error code="FOAR0002"/>

DONE as suggested

> - "prod-TryCatchExpr" test set "try-catch-optimizations-1" - the result is a
> sequence of 2 items

My suggestion here (and I have made the change) is the following:
<assert-deep-eq>0, 1</assert-deep-eq>