This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test: string-to-codepoints("e") eq 101 does not static type check as the types are LHS: interger* RHS: anyAtomicType? As has happened with similar cases, could "101" be set as the expected result for the test harness to check, rather than doing such a test in the query.
Yes, that is a good fix to this problem.
(In reply to comment #1) >> for the test harness to check, rather than doing such a test in the query. > Yes, that is a good fix to this problem. > It avoids the problem, but it does highlight that there is something deeply worrying about the current definition of XQuery if static typing is enabled, that it is so much more convenient to compare two XQuery values for equality -outside- of XQuery, rather than compare them using any expression within the defined XQuery language. David
>It avoids the problem, but it does highlight that there is something deeply worrying about the current definition of XQuery if static typing is enabled, that it is so much more convenient to compare two XQuery values for equality -outside- of XQuery, rather than compare them using any expression within the defined XQuery language. Well, that's not quite true. You could compare them using "=". After all, "eq" was invented largely in order to allow the system to throw static type errors, so people who use it get what they deserve. I do agree that all these bugs are tending to make me more and more convinced that static typing is a bad idea. Michael Kay
Another scary thing is that we previously have had two-three vendors running the test suite with static typing implementations but haven't reported the ones we've received lately(although they have reported on other stuff). That tells a bit about the interoperability of static typing implementations.
Comment 1 says: LHS: interger* RHS: anyAtomicType? The RHS is an integer literal, with type xs:integer. Replacing eq with = is the easy fix for this bug.
(In reply to comment #5) Ah, sorry, when I said LHS and RHS what I actually meant was the actual and expected type parameters of the created fs:convert-operand expression. Replacing eq with =, or moving the check to the test harness both sound equally good to me.
An attempted fix has been committed to CVS, and should be part of XQTS_current.zip. Feel free to verify that the fix is acceptable, and if so, change status to CLOSED. If the attempted fix is not acceptable, reopen this report. If no opinion about this resolution is expressed within two weeks, it will be closed. Along with the fix for this report, was committed fixes for other reports as well. Also, a significant amount of new tests were added to cover missing areas and changes in the specifications.