This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4046 - Static typing: ForExprType049 - ForExprType053, ForExprType025 - ForExprType027
Summary: Static typing: ForExprType049 - ForExprType053, ForExprType025 - ForExprType027
Status: CLOSED FIXED
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: 1.0.2
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Frans Englich
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-08 17:38 UTC by Tim Mills
Modified: 2007-09-14 13:34 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2006-12-08 17:38:01 UTC
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
Comment 1 Tim Mills 2006-12-12 17:57:45 UTC
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.

Comment 2 Frans Englich 2007-09-14 11:35:44 UTC
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?
Comment 3 Tim Mills 2007-09-14 13:06:00 UTC
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.
Comment 4 Frans Englich 2007-09-14 13:25:17 UTC
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.
Comment 5 Tim Mills 2007-09-14 13:34:16 UTC
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.