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 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?)
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.
Assertion changed to error, with code XPTY0004.
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.
*** Bug 11584 has been marked as a duplicate of this bug. ***
The bug #6988 might prove helpful in getting to a resolution on this bug issue.
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.
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.
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+
Thanks.