21960 2013-05-08 03:37:04 +0000 FOTS test case K2-ExternalVariablesWith-22 should raise XPTY0004 2013-06-14 14:38:57 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Working drafts PC Linux CLOSED FIXED P2 normal --- 1 markos_za oneil mike tim public-qt-comments oldest_to_newest 87402 0 markos_za 2013-05-08 03:37:04 +0000 I think that test case K2-ExternalVariablesWith-22 (in prod-VarDecl.external) should raise XPTY0004 instead of returning a result. This is because the type of the <e/> constructed node is xs:anyType, given that the default construction mode is preserve. So, <e/> is not an instance of element(*, xs:untyped?) 87713 1 mike 2013-05-15 11:18:57 +0000 I think you are right. Odd that no-one has tripped over this before. It might be because most processors don't evaluate a global variable that is unreferenced, or perhaps because non-schema-aware processors treat all data as untyped. 88896 2 oneil 2013-06-07 11:23:09 +0000 Assertion changed to error, with code XPTY0004. 89055 3 tim 2013-06-11 09:26:46 +0000 We do not report an error on this test case for the following reason. <e /> is of type element(e, xs:anyType) The declared type of $v is element(*, xs:untyped?)+ Purely on use of the type information available, there exist values which match element(e, xs:anyType) and element(*, xs:untyped?)+. Therefore this is postponed to a runtime (dynamic) check. Since $v is never evaluated, this dynamic type check is never invoked, and therefore the dynamic error is never raised. Thus the processor is entitled to return 1. Generally, given a variable $v which is never evaluated, since a processor may implement dynamic type checking, any type check errors in the definition of $v may be legitimately ignored. 89077 4 oneil 2013-06-11 12:08:20 +0000 *** Bug 11584 has been marked as a duplicate of this bug. *** 89090 5 oneil 2013-06-11 14:47:06 +0000 The bug #6988 might prove helpful in getting to a resolution on this bug issue. 89251 6 mike 2013-06-13 13:25:28 +0000 This test seems to have a long and unhappy history (see also bugs 11584 and 6988). There seem to be two separate issues. The first issue is that a processor that does dynamic type checking isn't obliged to raise any error because the global variable is never evaluated. To remove that problem, I propose to change the test to: declare variable $v as element(*, xs:untyped?)+ := <e/>; exists($v/*) The second issue is whether a processor is allowed to make the element untyped rather than anyType. This is the subject of bugs 11585 and 20828. I believe the outcome of these bugs is that if a processor does not support the typed data feature, then the constructed element will be untyped. I am therefore proposing to split the test into two, with dependencies to require the typed data feature to be on or off, and results false or error respectively. 89268 7 tim 2013-06-13 16:08:04 +0000 Test variant K2-ExternalVariablesWith-22a is marked as XQ10+, but prohibits the typed data feature in the catalog. Since XQuery 1.0 never had a typed data feature, this seems a little strange. 89273 8 mike 2013-06-13 17:23:38 +0000 Well, we could make either or both tests be XQ30+ only. We would lose a test that existed for 1.0, but its interpretation in 1.0 was never clear-cut. I'll mark them both as XQ30+ 89313 9 tim 2013-06-14 14:38:57 +0000 Thanks.