9258 2010-03-17 00:00:42 +0000 Static typing tests do not account for earlier static error 2010-06-08 21:56:35 +0000 1 1 1 Unclassified XQuery Update Facility Test Suite XQuery Update Facility Test Suite unspecified All All CLOSED FIXED P2 normal --- 1 josh.spiegel jmdyck jmdyck josh.spiegel liam zhen.liu public-qt-comments oldest_to_newest 33639 0 josh.spiegel 2010-03-17 00:00:42 +0000 The following tests: stf-insert-into-01 stf-insert-after-01 stf-replace-node-01 stf-replace-value-of-node-01 stf-rename-01 stf-transform-01 Can throw XPTY0004 before the error the test expects occurs. The reason is that they contain path expressions like: $input-context/works/employee[@name='Jane Doe 1'] $input-context has the static type document-node() or item()* depending on if a "as document-node()" rewrite described in the XQUTS guidelines is used or not. Either way, the derived content type of @name will be anyAtomicType. Consequently, the the static type check on the comparison between anyAtomicType and string will fail with XPTY0004. These tests should be modified so that XPTY0004 can not occur and the intended error condition is always tested. 33723 1 zhen.liu 2010-03-19 21:32:05 +0000 in http://dev.w3.org/2007/xquery-update-10-test-suite/TestSuiteDocumentation/Guidelines%20for%20Running%20the%20XML%20Query%20Update%20Test%20Suite.html, we shall add (xs:untyped) in document-node() definition Users of static typing may choose to transform the variable declarations between insert-start and insert-end comments by adding an "as document-node(xs:untyped)" clause as illustrated below: 33724 2 josh.spiegel 2010-03-19 22:08:59 +0000 Sounds good. I verified that modifying our test framework to rewrite the variable declaration using "as document-node(element(*, xs:untyped))" fixes the problem. Thanks. 33811 3 josh.spiegel 2010-03-23 16:50:11 +0000 Why was this closed? It does not appear that the guidelines have been changed yet. Why is this bug "invalid"? 33814 4 andrew.eisenberg 2010-03-23 19:21:46 +0000 Apologies. I read your issue and Zhen's response too quickly and thought that you were satisfied with our current guidelines. I believe that you are asking us to extend the guidelines, allowing the adding of both "as document-node()" and "as document-node(element(*, xs:untyped))". I'm not strong in our static typing, so I'll have to ask some of our other members to comment on this. I note that we've had similar requests in the past in Bug #3012, Bug #3972, Bug #4046, and Bug #7216. 33817 5 josh.spiegel 2010-03-23 19:31:26 +0000 No problem. Yes, your understanding is correct. Another option is to modify the 6 tests. Thanks. 33821 6 zhen.liu 2010-03-23 21:38:30 +0000 Allowing users to set document-node(element(*), xs:untyped) shall solve the problem without modifying the tests. However, We need to state so in http://dev.w3.org/2007/xquery-update-10-test-suite/TestSuiteDocumentation/Guidelines%20for%20Running%20the%20XML%20Query%20Update%20Test%20Suite.html 33824 7 andrew.eisenberg 2010-03-23 22:47:43 +0000 (In reply to comment #6) > Allowing users to set > document-node(element(*), xs:untyped) > shall solve the problem without modifying the tests. Zhen, is this a necessary change? Is there a problem with these test cases if only "as document-node()" is added? 33826 8 zhen.liu 2010-03-23 22:58:11 +0000 If only static type of 'docuement-node()' is used, then it means the input document could be either untyped or typed, so this means the conservative static typing has to raise static type errors for comparison in the predicate employee[@name='Jane Doe 1'] since @name might be xs:integer, so it is an error to compare with xs:string. This is what Josh explained in the original bug comment. However, if we set the static type to 'document-node(element(*, xs:untyped)), then no static type error is raised for handling the predicate comparison. So the real intention of the test to test static typing for updating expression is realized. 33982 9 jmdyck 2010-03-28 06:04:18 +0000 (In reply to comment #5) > Another option is to modify the 6 tests. E.g., by changing "@name" to "(@name treat as xs:string)" ? 33983 10 josh.spiegel 2010-03-28 17:15:06 +0000 I would rewrite them as follows: $input-context/works/employee[@name='Jane Doe 1'] becomes $input-context/works/employee[1] 33988 11 jmdyck 2010-03-28 18:55:00 +0000 I don't think that would entirely work. The point of an expression like $input-context/works/employee[@name='Jane Doe 1'] is that its static type has cardinality greater than one, but its value has cardinality one. (So an implementation that supports the Static Typing Feature will raise a type error during static analysis, but an implementation that doesn't support the STF won't raise a type error at all.) With an expression like $input-context/works/employee[1] then, yes, when $input-context has the default static type item()*, the expression will still have the properties given above. But if an implementation chooses to replace the default declaration with: declare variable $input-context as document-node() external; then I believe the Formal Semantics rules would cause it to infer a static type of cardinality zero-or-one for the expression, and therefore not raise a type error. 33990 12 josh.spiegel 2010-03-28 19:12:21 +0000 You are right, I forgot you need the *. Would $input-context/works/employee work? 33999 13 jmdyck 2010-03-28 20:44:52 +0000 No, because then both the STF and non-STF implementations would raise a type error. 34093 14 josh.spiegel 2010-03-29 18:56:00 +0000 OK, then could we do a slight variation on your original suggestion? "@name" to "@name treat as attribute(name, xs:string)" or even "@name" to "data(@name) treat as xs:string" Sorry, I am not trying to be difficult :) With your original suggestion, our implementation detects that even with the treat expression, it is impossible for "attribute (name, anyAtomicType)" to become "xs:string" at runtime so it still fails statically. Note, the input to the treat expression is not atomized. 34637 15 zhen.liu 2010-04-07 22:08:23 +0000 (: Name: stf-insert-into-01 :) (: Description: insert-into: ST of TargetExpr has cardinality greater than one. :) The purpose of this test is to show ST raises static type error by infering the $target has static type with occurance of either 'zero or one', or 'zero or more'. So $input-context/works/employee[1] shall raise static type error as the ST is zero or one of element(employee) and $input-context/works/employee[@name='Jane Doe 1'] shall raise static type error as the ST is zero or more element(employee) $input-context/works/employee[@name='Jane Doe 1'] shall raise static type error as the ST is zero or more element(employee) So as long as we set the static type for $input-context to 'document-node(element(*, xs:untyped)), the expected static type would be raised without the need of changing the tests. 34638 16 josh.spiegel 2010-04-07 22:13:58 +0000 Zhen - I agree that changing the guidelines or changing the tests will fix the problem. Why do you think changing the guidelines is better? 34639 17 zhen.liu 2010-04-07 22:25:39 +0000 No difference between changing the tests or the guideline of setting $input-context to 'document-node(element(*, xs:untyped)). However, in general to really test more on static typing (pessimistic based), it helps more to set $input-context to 'document-node(element(*, xs:untyped)) instead of setting $input-context to 'document-node(element(*)). 34640 18 jmdyck 2010-04-08 00:31:21 +0000 Currently, the XQUTS guidelines *allow* the test harness to add as document-node() to the decl for $input-context. In order for the six tests in question to work unchanged, we'd have to *require* the test harness to add as document-node(element(*, xs:untyped)) So that's two changes. Moreover, I believe there are test-cases in XQUTS for which requiring that addition could cause problems. E.g., for a query involving books.xml, if an implementation constructs a typed XDM instance for the document, then it can't bind that value to a variable that has been declared as document-node(element(*, xs:untyped)). So the guidelines would have to address that somehow. If instead we change the six queries, then the guidelines (and thus test harnesses) don't need to change. (My guess is that it's easier for implementors to rerun the suite with changed queries than it is for them to change their test harnesses.) A third approach would be to change the six queries, but rather than tweaking the @name in the query body, explicitly add "as document-node(element(*, xs:untyped))" to the declaration of $input-context. 35268 19 jmdyck 2010-04-27 17:13:01 +0000 Josh, how do you feel about my "third approach"? (Explicitly change the declared type of $input-context in those six queries, and leave the query bodies as is.) 35269 20 josh.spiegel 2010-04-27 17:29:24 +0000 So to recap, I think we have three viable options suggested: (a) Modify the queries with something like "@name treat as attribute(name, xs:string)" (b) Modify the test guidelines to require a rewrite of the variable declaration as "document-node(element(*, xs:untyped))" (c) Modify the queries to rewrite the variable declaration as "document-node(element(*, xs:untyped))" Based on what Michael points out in Comment #18, I would vote against (b). I would be happy with (a) or (c). 36056 21 jmdyck 2010-06-08 21:55:54 +0000 At its meeting on 2010-05-18, the XQuery WG decided to adopt the solution given as option (c) in comment 20. I have made the necessary changes (in both XQuery and XQueryX versions of the queries) in XQUTS. Therefore, I am marking this bug resolved-FIXED. Since you said you would be happy with this option (c), I am also taking the liberty of marking this bug CLOSED.