This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I presume I have made some silly mistake, but I get type checking errors when attempting to compile these queries. Our XQTS implementation modifies the $input-context variable to be of type document-node(). Given this, we deduce the type of $input-context/root/InterleaveType/* to be a sequence of zero or more element() of xs:anyType. The return type of fn:data is therefore deduced to be xs:untypedAtomic*. This then fails the "as xs:decimal" part of this expression. Note that if we were able to rewrite the query to be more specific about the type of $input-context, we would pass this test. That's doesn't appear to be possible because the type of element root is anonymous. Would anyone be so kind as to point out what we've done wrong? (: Name: ForExprType049 :) (: Description: FLWOR expressions with type declaration. Non-trivial value type promotion: Interleave value type integer|decimal -> decimal :) (: insert-start :) import schema default element namespace "http://typedecl"; declare variable $input-context external; (: insert-end :) for $test as xs:decimal in data( $input-context/root/InterleaveType/* ) return $test
This problem also applies to ForExprType025-ForExprType027. I believe the problem boils down to the following issue: From Formal Semantics 2.4.2 element * of type xs:anyType is a type for any element. Also, in FS 7.2.6 "When applied to an element type whose type annotation denotes a complex type of mixed content, the data on filter returns xs:untypedAtomic." and in XQuery 2.5.2 "If the type annotation is xs:untyped or xs:anySimpleType or denotes a complex type with mixed content (including xs:anyType), then the typed value of the node is equal to its string value, as an instance of xs:untypedAtomic.." Therefore I believe the following three judgements to be correct. -------------------------------------------------------- data on element * of xs:anySimpleType : xs:untypedAtomic -------------------------------------------------- data on element * of xs:untyped : xs:untypedAtomic -------------------------------------------------- data on element * of xs:anyType : xs:untypedAtomic Now, from FS, we know -------------------------------------------- data on element * of xs:integer : xs:integer I find it strange that if element * of xs:integer is a subtype of element * of xs:anyType then data on element * of xs:integer is not a subtype of data on element * of xs:anyType because xs:integer is not a subtype of xs:untypedAtomic. They are related only by the "can be promoted to" judgement.
I fail to see the issue with 026 and 027. The former reads: for $test as attribute( att,Enumeration ) in $input-context/root/UserDefinedSimpleTypeAttribute/@att return data( $test ) In what way does this fail static type checking?
This now works in our implementation. We raised Bug 4273 with regard to the FS rules for data on. Note that to get this (and similar tests) to pass static typing, we believe it is _required_ that the type of the input context be defined as: declare variable $input-context as document-node(schema-element(root)) external; This is painful because we actually have to read the input document so that we work out how to modify the query appropriately.
If there are no tests to fix, can I then close this report? I can sympathize with static type checking being painful. To me, most concerning it turns out to be.
It would be nice to have the tests in the Schema Import Feature section modified to use declarations of the form: declare variable $input-context as document-node(schema-element(root)) external; ...but you probably have enough to do maintaining these tests! Thanks for all your work.