fwiw, I believe ST-WhereExpr001 can fail against the static typing rules. See for example bug 2943 and bug 2942.

(In reply to comment #1)
> fwiw, I believe ST-WhereExpr001 can fail against the static typing rules.

True, but that is because the static typing rules for fn:boolean do not match the informal description in "Functions and Operators".  So is the error in:
(a) Functions and Operators - and the main XQuery specification; or
(b) the Formal Semantics - and ST-WhereExpr001?

Pity the inconsistency wasn't fixed earlier.

I think this is a Static Typing test. Static typing often fails where dynamic typing succeeds. 

>True, but that is because the static typing rules for fn:boolean do not match
the informal description in "Functions and Operators". 

I don't understand this comment. Section 15.1.1 in F+O doesn't attempt to describe the static typing rules for fn:boolean, even informally. It explicitly states that the static typing rules are to be found in the Formal Semantics document.

The static typing rules are not supposed to define a separate language.  They are supposed to defined a set of computable (and hence conservative) rules for staticing determing whether an XQuery program is type-correct.  Because of the limits of computability, and because we want to be conservative, sometimes static typing will reject a program that works fine.  However, that is not the goal: The goal is that if we had perfect computability, then static typing would reject a program if and only if there is some set of inputs that would cause the program to fail at runtime.

The distinction between the dynamic and static semantics for fn:boolean seems to violate that goal.  Even for this trivial program it is unclear if it is valid:
  fn:boolean(<a/>, 1)

Now I can see the efficiency argument for not having to test every item in a sequence.  One solution is to make unspecified the result of fn:boolean on a hybrid sequence starting with a node - allow an implementation to yield either true or an error,

At the very least the test-case needs to be fixed too allow it to not fail.

There is a bit of "standard" history behind that behaviour. There is really no good semantic meaning for fn:boolean on heterogeneous sequences. E.g., fn:boolean((<a/>, false()))... should that be true, false? So some people wanted this to be an error (especially since it is also being used in the context of predicates as the implied semantics). Other people that have runtime semantics, did not want to evaluate 2000 values before hitting the heterogeneity and wanted a more performant semantics. So we decided, as a compromise, to make this a static error, but have efficient, dynamic semantics for the implementations, that do not do static analysis.

(In reply to comment #6)
That makes sense and that is why I suggested in #5 to make the dynamic semantics of fn:boolean((NODE, .., ATOMIC ...)) unspecified, allowing implementations to return either true or error.

But in any case, the testsuite should be fixed to allow but not require an error.

Since ST-WhereExpr001 is a test for the optional Static Typing Feature, it means at least to me that implementations not implementing the Static Typing Feature, should not run it.

By that my conclusion is that the output is irrelevant, since static typing implementations must trigger a static type error(as per mrys' comment).

Per, does your implementation support the Static Typing Feature?

(In reply to comment #8)
> Since ST-WhereExpr001 is a test for the optional Static Typing Feature, it
> means at least to me that implementations not implementing the Static Typing
> Feature, should not run it.

The XQTSCataLog.xml file describes the scenario as "runtime-error".

I don't see anything in the XQTS documenttaion or in XQTSCatalog.xml to say that implementations not implementing the Static Typing should not run this test, except maybe keying off the StaticTyping  directory in the FilePath.  That seems a bit of a kludge.

> By that my conclusion is that the output is irrelevant, since static typing
> implementations must trigger a static type error(as per mrys' comment).
> 
> Per, does your implementation support the Static Typing Feature?

No - it does some ad-hoc static typing, so it catches some type errors at compile time.

I agree that the documentation doesn't say that tests in the "Optional Features" group mustn't be run. Have a look at:

http://www.w3.org/XML/Query/test-suite/XQTSReportSimple.html

For several of the optional features the fields are white, meaning they are untested for that implementation. For instance, the implementation BaseX hasn't run the tests for Schema Import Feature, and Anglo doesn't support the Static Typing Feature.

The optional feature-tests are designed for testing those optional features, so if one doesn't implement it, they will obviously fail. For instance, Constr-compelem-constrmod-1 doesn't allow XQST0009, which an implementation that doesn't support Schema Validation, will raise.

Same goes for ST-WhereExpr001. An implementation implementing the static typing feature, must raise FORG0006, and that's what the test tests.

For my own driver I do this by letting the code that reads the catalog file, skip the whole sub-tree if a category is encountered whose name is a category Patternist doesn't support.

I'm closing this report, since ST-WhereExpr001, which tests optional static typing, was run using a non-static typing implementation(see comment #10).

If this resolution is satisfactory, feel free to change status to CLOSED. Otherwise reopen this report. If no feedback is given within two weeks, status will be set to CLOSED.

Just an extra comment: If it is deemed that this test should fail because of the static typing rule in the formal semantics, then surely the error code should be XPTY0004 rather than FORG0006? The same goes for ST-WhereExpr002, and statictyping-7