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 is a follow-on to bug #10291 against test case module-schema-context. The essence of the test is that a function F in module M1 returns a value of type my:int which is a subtype of xs:int; the caller in module M2 tests "F() instance of xs:int", when my:int is not imported into M2. The originator of the bug considered that a valid result for this test was XPTY0004; the WG decided (it appears) that such a result would be unacceptable from a usability and interoperability perspective, and that the spec therefore needed to be "clarified". There has been some attempt to clarify the rules here in the 3.0 spec, but they still leave this case implementation-defined. Firstly, the sentence "Some of the rules for SequenceType matching require determining whether a given schema type encountered as a type annotation in an instance document is the same as or derived from an expected schema type." needs to be generalized so that it also covers type annotations on atomic values (which as in this example can be produced by casting, not only by validation). Secondly, the rule 2. potentially, the schema used for validating the instance document; whether a processor adds this schema to S is implementation-defined. allows a processor to return XPTY0004 for this test query, and it appears that we want to disallow that. To achieve this, I believe we should change the rules to: <new> Some of the rules for SequenceType matching require determining whether a given schema type T encountered as the dynamic type of an XDM value is the same as or derived from an expected schema type. This determination is done by reference to a schema S (that is, a set of schema components). This schema S is the union of: 1. the in-scope schema definitions in the static context of the module. 2. the type definition T 3. the base type of every type that is present in S 4. potentially, further schema components that have been made available to the processor in an implementation-defined way. </new> and then delete the paragraph starting "Whether the schema..." If we want to disallow an XQuery 1.0 processor from returning XPTY0004 for this query then we also need a corresponding erratum to XQuery 1.0.
For XQuery / XPath 3.0, I believe this is now clear due to the resolution of http://www.w3.org/Bugs/Public/show_bug.cgi?id=11095#c6. I'm moving this to the errata against the 2ed specifications.