This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In test set prod-CastExpr.derived, the test cbcl-cast-date-004: "18446744073709551616-QQ-15" cast as xs:date expects error FORG0001. However it appears that FODT0001 should also be accepted. See section 19.2 of the FO31 spec, which specifies: "In casting to xs:date, xs:dateTime, xs:gYear, or xs:gYearMonth (or types derived from these), if the value is too large or too small to be represented by the implementation, a dynamic error [err:FODT0001] is raised." and "If the cast fails for any other reason, a dynamic error [err:FORG0001] is raised." Similarly for test cbcl-cast-dateTime-004
> if the value is too large or too small to be represented by the implementation, > a dynamic error [err:FODT0001] is raised. I have had a similar discussion a while back (can't remember the bug id), but I believe this was *only* for cases were facets are out of bounds, *after* parsing. The question is, is this date format invalid ("QQ") or is it overflowing ("18446744073709551616"). I'd argue that any type first needs to be parsed before it gets converted into an internal data representation, in which case this would *not* be an overflow case, but an invalid date case. Note, from a parsing perspective, the XSD facet for year allows "18446744073709551616". So, during parsing and facet validation, this part is valid, only after that the overflow *may* kick in, but we never get that far.
Abel: it's very common these days (and probably always has been) for the different phases of static analysis (tokenization, syntax analysis, semantic checking) to be done in parallel, rather than finishing one phase before the next one starts. You're suggesting that when processing dates, syntax analysis has to complete before semantic anaylsis starts. I don't find any statement in the spec that supports this position.
> You're suggesting that when processing dates, syntax analysis has to > complete before semantic anaylsis starts. I don't find any statement > in the spec that supports this position. I wholeheartedly agree and glad you say so, it requires less special-casing in an implementation. I think this is a good thing. The way I read the errors and the spec and the way I made some changes in the past was precisely because I thought parsing comes first, then the rest (which is only relevant for a certain class of errors, most notably the overflow ones). It'd be nice if there is no necessity to do so and to be lenient with errors like these.
Note also that the grammar allows the year part of the date to be indefinitely long, so in any system with a limit on the length of strings, there are going to to be some cases where the system hits a limit even though the date is syntactically valid.
I have resolved this bug by adding the extra error code in the test cases as suggested in comment #0