3576 2006-08-02 14:28:56 +0000 static-context-1 should raise XPTY0004 2006-12-11 20:43:51 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Windows XP RESOLVED FIXED P2 normal --- 3650 1 marc.van.cappellen carmelo simeon public-qt-comments oldest_to_newest 10995 0 marc.van.cappellen 2006-08-02 14:28:56 +0000 The test static-context-1 expects today XPST0001. We believe that, if not the only correct answer, that at least XPTY0004 should be added as an alternate expected error code. The query is as follows: declare namespace test = 'http://www.example.com'; <a/> instance of element(*, test:unknownType) Why XPTY0004? instance of refers to the sequencetype mathcing rules. In "2.5.4 SequenceType Matching" we read: "derives-from(AT, ET) raises a type error [err:XPTY0004] if: ET is an unknown type, or ..." Why not XPST0001? The description of XPST0001 reads as follows: It is a static error if analysis of an expression relies on some component of the static context that has not been assigned a value. The error description clearly says "some component has not been assigned a value". Ok, test:unknownType is not known to the "In-scope schema defintions". But still, there is a value assigned to the "In-scope schema defintions" in our implementation. Thanks, Marc 11013 1 andrew.eisenberg 2006-08-03 18:17:38 +0000 You've made a good case for adding XPTY0004. I'm less convinced that XPST0001 should be removed. As you say, the error description says "some component has not been assigned a value". Without thinking, I had expanded this error to include missing definitions within the In-Scope Schema Definitions. Perhaps Jerome will give us an opinion on whether XPST0001 should be retained. 11015 2 carmelo 2006-08-03 20:31:00 +0000 Marc: Thanks for the commnet. I added the extra expected error code. Will leave the bug open for now, pending an answer from Jerome. Thanks, Carmelo 11081 3 simeon 2006-08-10 05:12:02 +0000 That's a tricky case here I think. I admit my opinion is that the spec is unclear. My first intuition is that XPST0001 should takes precedence. I.e., checking whether the type 'test:unkonwnType' is in the context, should occur before type matching is applied. A corrolary of that is that I think bullet '1 ET is an unknown type' should actually never be used. Because of the way the spec is written now, I would assume that keeping both error codes in the test suite is the right thing to do as implementations may actually do either one of those. But I would recommend asking the working group to clarify this. sorry I can't give a more definite answer to this right now. Best, - Jerome 11340 4 carmelo 2006-08-31 15:10:30 +0000 Does anyone knows if the Working Group will look into this?. Otherwise, I will close the BUG as fixed with both error codes allowed. Thanks, Carmelo 11371 5 frans.englich 2006-09-04 13:42:59 +0000 They will now: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3650 Frans 11515 6 carmelo 2006-09-08 14:24:13 +0000 All: We will wait a resolution from the working group as requested on http://www.w3.org/Bugs/Public/show_bug.cgi?id=3650 Thanks, Carmelo 12061 7 carmelo 2006-09-26 17:38:20 +0000 Mark: Given the response from the WG that teh are in question is a bit unclear, both codes will be left on the expected set of results from the time being. Thanks, Carmelo 12501 8 frans.englich 2006-10-16 20:49:07 +0000 Reopening; the working group has resolved this bug now, and the error code is not XPST0001 nor XPTY0004, but XPST0008: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3650 Frans 13134 9 carmelo 2006-12-11 20:43:51 +0000 Marc/Frans et all: Thanks for the follow up on this. I chnaged the catalog file to reflect the new code. Thanks, Carmelo