This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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
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.
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
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