3717 2006-09-13 11:55:09 +0000 Cardinality inference for 'cast as' should take operand into account 2006-09-27 09:46:11 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Candidate Recommendation Other Linux CLOSED WONTFIX P2 normal --- 3651 3686 1 frans.englich simeon public-qt-comments oldest_to_newest 11646 0 frans.englich 2006-09-13 11:55:09 +0000 Recently, there has been reports on tests in the XQTS which uses cast expressions as operands to expressions that expects exactly-one. An example: fn:dateTime(xs:date("1999-12-31"), xs:time("12:00:00")) This query contains two type errors, because the operands are typed as xs:date?/xs:time? while xs:date/xs:time is expected. One runs easily into this problem, because as soon one wants to specify a literal using a constructor function, one gets a type error, which to me seems counter intuitive. Therefore, I suggest to change the inference rule for 'cast as' to have as cardinality exactly-one if its operand's cardinality is exactly-one(that is, whether the '?' is specified is ignored for computing the static type). See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3686 http://www.w3.org/Bugs/Public/show_bug.cgi?id=3651 11670 1 mrys 2006-09-13 20:28:11 +0000 While special casing the inference solves the particular problem, often the arguments to fn:dateTime() will be provided using some expressions that will infer optionality in their static type. So this proposal will only solve a small subset and will not address the general issue. The general issue should be (and has been) resolved by widening the accepted type range for fn:dateTime(). Best regards Michael 11772 2 frans.englich 2006-09-15 09:55:09 +0000 I agree the proposed change is a patch in the traditional sense. However, I think it's a large patch. That is, that most of these problems are caused by cast expressions. I have a hard time understanding relaxing signatures. That static typing decreases usability is a consequence -- a trade off. The point of static typing is to reduce branching/possibilities in the implementation, and relaxing a signature is doing the opposite. I'm not opposed to relaxing fn:dateTime, I just have a hard time understanding it, since it to me seems contradictory to why people wanted static typing in the first place. 11842 3 simeon 2006-09-18 23:48:17 +0000 It seems that if users are able to write functions like that: xs:date(if (cond()) then () else "1999-12-31") then static typing must be consistent with the dynamic semantics. Another example is when using arithmetics: declare function mycast($floatvalue as xs:float?) as xs:decimal? { xs:decimal($floatvalue * 0.2E-5) }; So either such queries should type check (which is what currently happens), or someone has to decide that constructors functions cannot take an empty sequence. Either way, I think either change is too big for the stage of development XQuery is right now. - Jerome 12037 4 simeon 2006-09-26 14:08:16 +0000 Frans, Thanks for your comment. The XSLT and XML Query Working groups have discussed this issue and decided that it was too late in the process to revisit the decisions in that area, and to close the bug with no further action. Please let us know if you can live with that decision. Best, - Jerome On behalf of the XSLT and XML Query WGs