[Bug 3686] fn-matches2args-1 fails static typechecking.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3686





------- Comment #6 from frans.englich@telia.com  2006-09-10 11:20 -------
Many of these recent static typing reports are because of the 'cast
as'-inference isn't very clever(I think). It doesn't infer from its operand,
but blindly goes on whether the '?' occurrence indicator has been specified:

-----------------------------------------------------
[Expr cast as AtomicType ]
  ==
  let $v as xs:anyAtomicType := fn:data(([ Expr ]Expr)) return
    $v cast as AtomicType

  [Expr cast as AtomicType? ]Expr
  ==
  let $v as xs:anyAtomicType? := fn:data(([ Expr ]Expr)) return
    typeswitch ($v)
      case $fs:new as empty-sequence() return ()
      default $fs:new return $v cast as AtomicType
-----------------------------------------------------

I suspect many implement an inference that takes into account whether the
operand's static type's cardinality allows the empty sequence(I know at least
two impls.), and for that reason we receive these reports first now.

I think it would be sensible to make 'cast as' smarter here(FS change) because
it would make static typing behave as non-static typing in the reported cases.
People expect passing xs:foo("value") to work, because it's XPath's way of
creating literals for some values.

Of course, this is only a fix when the arguments to functions are cast
expressions, but I can't come to think of other cases(well, there surely are,
but the question is how widely used).


Frans

Received on Sunday, 10 September 2006 11:20:26 UTC