This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Queries such as: fn:matches(xs:string("This is a characte"),xs:string("This is a characte")) from: fn-matches2args-1 fail under static type checking, because fn:matches($input as xs:string?, $pattern as xs:string) as xs:boolean xs:string($arg as xs:anyAtomicType?) as xs:string? i.e. the second argument is not guaranteed to return a string. It may return an empty sequence.
Other offending queries include: fn-replace3args-1 fn-matches2args-1 to fn-matches2args-5 fn-replace3args-1 to fn-replace3args-7
> fn:matches(xs:string("This is a characte"),xs:string("This is a characte")) If this isn't a valid query then we've clearly got something badly wrong, and it's not just the test case. Static Typing is identified in the CR as an "at risk" feature and this kind of report is leading me strongly to the view that we should pull it from the Rec and take more time to get it right. IIRC, there was some pressure from Static Typing implementors to relax the signatures of some functions and operators (like matches) so that queries like the one above would work, and there was resistance from other implementors because it would reduce the ability for dynamic typing to detect errors. Perhaps we should think about allowing functions and operations to have a weaker type signature when static typing is in use. Or perhaps we need to make the type inference machinery more intelligent so that it (like any human being) can infer that the above example is actually type safe. Michael Kay (not speaking for the WG, of course)
A simple fix might be to require that all constants are folded before static typing occurs?
A formal definition of constant subexpressions might well be useful, but I don't think it would be simple. Michael Kay
I was arguing in favor of relaxing the argument types to make them composable. But examples as the one given is of a lesser concern since xs:string("This is a characte") is bad coding style. Our static typing implementation actually relaxes the argument types of these built-in functions to allow (). We should either do that change for at least static implementations - or if no consensus can be reached, we should allow static typing implementation to error on the test.
Many of these recent static typing reports are because of the 'cast as'-inference isn't very clever(I think). It doesn't infer from its operand, but blindly goes on whether the '?' occurrence indicator has been specified: ----------------------------------------------------- [Expr cast as AtomicType ] == let $v as xs:anyAtomicType := fn:data(([ Expr ]Expr)) return $v cast as AtomicType [Expr cast as AtomicType? ]Expr == let $v as xs:anyAtomicType? := fn:data(([ Expr ]Expr)) return typeswitch ($v) case $fs:new as empty-sequence() return () default $fs:new return $v cast as AtomicType ----------------------------------------------------- I suspect many implement an inference that takes into account whether the operand's static type's cardinality allows the empty sequence(I know at least two impls.), and for that reason we receive these reports first now. I think it would be sensible to make 'cast as' smarter here(FS change) because it would make static typing behave as non-static typing in the reported cases. People expect passing xs:foo("value") to work, because it's XPath's way of creating literals for some values. Of course, this is only a fix when the arguments to functions are cast expressions, but I can't come to think of other cases(well, there surely are, but the question is how widely used). Frans
Yes. Am I correct in thinking that all built-in type constructors called with a parameter of type anyAtomicType which is a non-empty sequence will either throw an error (because the form of the input is in some way wrong) or return a value of that type? If so, the type rules: statEnv |- QName of func in { set of built-in constructors } statEnv |- Expr : empty ------------------------------------------------------------- statEnv |- QName(Expr) : empty statEnv |- QName of func in { set of built-in constructors } statEnv |- Expr : Type quantifier(Type) in { 1 } ------------------------------------------------------------- statEnv |- QName(Expr) : Type should clear up many of the problems we've highlighted.
Answering your question: yes, I believe so(not taking into account any type/dynamic errors in the operand or its children, of course). However, I don't think the suggested inference rules in #7 would work because constructor functions are mapped to 'cast as' expressions. Therefore, I believe the inference rules-changes need to be done for 'cast as'.
There is the larger question of the inferred static type of constructor functions that has been brought to the WGs in 3717. For the several test cases mention in this report, however, a simple fix is to remove the xs:string constructor function. The query: fn:matches(xs:string("This is a characte"),xs:string("This is a characte")) can be rewritten as fn:matches("This is a characte","This is a characte")
All: Corrected the static typing failures by remving the constructor functions. The replace tests were generated automatially and it seems as though they are similar. When time allows, I will make the tests match the documentation. Thanks, carmelo