W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2006

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

From: <bugzilla@wiggum.w3.org>
Date: Sun, 10 Sep 2006 11:20:04 +0000
To: public-qt-comments@w3.org
Message-Id: <E1GMNM4-00034T-3W@wiggum.w3.org>


------- 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).

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:30 UTC