29027 2015-08-05 10:43:32 +0000 [qt3] contextDecl-022 2015-11-03 12:57:59 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.1 Last Call drafts PC All RESOLVED FIXED P2 normal --- 1 mike jonathan.robie jmdyck oneil tim public-qt-comments oldest_to_newest 122462 0 mike 2015-08-05 10:43:32 +0000 This test case does <environment> <context-item select="'London'"/> </environment> <test> declare context item as xs:string := 2; . </test> <result> <any-of> <error code="XPTY0004"/> <assert-eq>'London'</assert-eq> </any-of> </result> I have some questions here about interpreting the spec. Note that the context item is not declared "external". (a) Given that the context item is not declared external, is it acceptable for the query to accept an externally-supplied value? If not, "London" is not a valid result. (b) Saxon is actually producing a different error, saying that the query does not define an external context item and therefore it is an error to supply one. There's no such error defined in the spec, but it's a reasonable thing within the scope of API design. I think we should avoid tests that stray into API-defined territory, and supplying an external context item to a query that does not expect one falls into this area. 122996 1 oneil 2015-09-01 16:47:32 +0000 The WG agreed to reassign this bug against the spec. 123092 2 mike 2015-09-04 21:00:49 +0000 Reading the spec again, it says [the value of the context item is]: * If VarValue is specified, then the result of evaluating VarValue. which I think leaves little wriggle room for suggesting that it might instead be something from the external environment. I'd suggest adding a Note: Note: if a context item declaration is present, and "external" is not specified, then the context item cannot be supplied externally. It is outside the scope of this specification whether an attempt to supply a context item externally is ignored, or results in an error. We should change the test to remove the attempt to supply a context item externally, and remove "London" as a possible result. I'm not sure what to make of the statement in C.2 that the initial context item is "overwriteable" by implementations. If there's an initial context item declaration that gives the initial context item a value, I don't think we want to license implementations to ignore that. 123095 3 jmdyck 2015-09-05 02:22:26 +0000 (In reply to Michael Kay from comment #2) > > I'm not sure what to make of the statement in C.2 that the initial context > item is "overwriteable" by implementations. It made sense when the "Default initial value" of 'context item' was 'none', but not so much when it changed to 'the initial context item'. I was about to describe what, to me, would be the right way to incorporate the initial context item into that table, when I found that I already did so (Member-only): https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Dec/0034.html As far as I can tell, that message was never discussed at a meeting, and I must have just forgotten about it. But I still think it's correct. > If there's an initial context item declaration that gives the initial > context item a value, I don't think we want to license implementations > to ignore that. Indeed, that's what we decided with respect to your bug 19267. 123745 4 jonathan.robie 2015-10-16 20:58:18 +0000 This was fixed in passing when I addressed the same comment in Bug 29170. 123746 5 jonathan.robie 2015-10-16 20:59:23 +0000 Aaargh, I resolved the wrong bug. Reopening. 123817 6 tim 2015-10-21 10:08:43 +0000 Just to complicate matters, an imported module might declare an external context item, and the main module might declare it with VarValue. 124054 7 oneil 2015-11-03 12:57:59 +0000 test case changed accordingly to comment #2. Please close if happy with fix.