This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test claims to test the resolution of bug 4273, which is a very complex bug on the Formal Semantics with no less than 52 comments; it's very hard to work out what it's saying even if you know the Formal Semantics quite well. However, it's an extremely simple test case: it creates an element, validates it against a schema type with mixed content, and then atomizes it. The typed value of an element with mixed content is the string value as an instance of xs:untypedAtomic: there can't be any doubt on that. Yet the test is expecting an error FOTY0012, meaning that the element has no typed value.
(a) An implementation that does not support the Static Typing Feature will yield an xs:untypedAtomic value as you say. (b) An implementation that supports the STF based on 1st edition FS will, during Static Type Analysis, infer a static type of xs:untypedAtomic for the query, and then proceed as in (a). (c) An implementation that supports the STF based on 2nd edition FS will, during Static Type Analysis, fail to infer a static type for the fn:data() call, and instead raise FOTY0012. The test-case's expected result only admits (c). If we augment the expected result to admit (a), it will also admit (b), and the test-case will cease to have much point. (It certainly would no longer reflect the resolution of 4273 in any useful way.) Instead, perhaps we should simply move the test-case into the StaticTyping test-group, where (as I understand it), the expected results don't have to reflect the behaviour of an implementation that does not support the STF.
I disagree that a static typing implementation must raise an FOTY0012 error. In 4273 comment #49, Michael Dyck lays out several possible solutions to the problem that were considered. Whilst the working group settled with solution 1, it is permitted for an implementation to extend the static typing rules, and implement solution 2. In this case an implementation could notice that there are no types derived from the type of mc:letter and thus this error need not be raised (it could at this point infer that the static type is xs:untypedAtomic). Thus I believe that it should allow no error to be raised, even in static typing modes. In order to make this test watertight the schema needs to contain * a complex type, mc:mixed, with mixed content * a complex type, mc:elementOnly, restricting mc:mixed with element only content. The node cannot be directly constructed in the query, as then static analysis can identify the schema type of the node exactly. Thus the node must be passed in from the external context. I believe that with the proposed schema modifications the following test would behave appropriately: import schema namespace mc ="http://www.w3.org/XQueryTest/mixedcontent"; declare variable $node as element(*, mc:mixed) external; data($node) where $node is a document containing an element with type mc:mixed. This test would then always require FOTY0012 in static typing mode, but would return a result in dynamic typing mode.
I have removed the test fn-datacomplexcontent-1 and replaced it with a new test ST-Data001 which is as described in comment #2, and has been added to the StaticTyping group, as suggested in comment #1. FOTY0012 is the only result accepted by the test.