This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
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
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
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
They will now: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3650 Frans
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
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
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
Marc/Frans et all: Thanks for the follow up on this. I chnaged the catalog file to reflect the new code. Thanks, Carmelo