Created attachment 443 [details]
XQTS static type errors

*** Bug 4088 has been marked as a duplicate of this bug. ***

*** Bug 4164 has been marked as a duplicate of this bug. ***

With reference to K-NumericAdd-38, from my reading of the XQuery spec, it is unclear as to whether a static typing implementation should raise XPTY0004 during type checking when one of the arguments to the operator is the empty sequence and the other is of a type inappropriate to that operator.

From XQuery section 3.4:

"Each operand is evaluated by applying the following steps, in order:

1. Atomization is applied to the operand. The result of this operation is called the atomized operand.
2. If the atomized operand is an empty sequence, the result of the arithmetic expression is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.
3. If the atomized operand is a sequence of length greater than one, a type error is raised [err:XPTY0004]."

i.e. By stage (2) we may already have determined that the operator need not be applied; we know the result must be the empty sequence and there is no need to ensure that the operands are valid for the operator.

That said, the formal semantics spec doesn't seem to specify that in the static typing rules (section C.2), although in the dynamic evaluation description it does specify this behaviour.

The tests K-NumericAdd-40 nodecomparisonerr-1, K-NodeSame-2, nodecomparisonerr-2, K-NodeBefore-1, K-NodeBefore-2, nodecomparisonerr-3, K-NodeAfter-1, K-NodeAfter-2 raise similar issues.

Could someone please clarify this issue?

(:*******************************************************:)
(: Test: K-NumericAdd-38                                 :)
(: Written by: Frans Englich                             :)
(: Date: 2006-10-05T18:29:36+02:00                       :)
(: Purpose: Arithmethics involving operands of integer type but with wrong cardi
nality. :)
(:*******************************************************:)
empty((1, 2) + ())

*** Bug 4182 has been marked as a duplicate of this bug. ***

Regarding K-SeqExprTreat-11, 12 and 15, you might find some of the discussion
in bug report 3818 to be relevant.

I believe nametest-9 to be correct.  Quoting from the formal semantics spec,

"A computed element constructor creates a new element with either the type annotation xs:untyped (in strip construction mode), or with the type annotation xs:anyType (in preserve construction mode)"

and therefore that the type assigned to $var does not permit you to deduce the error "path does not contain empty-node-list".

: Name: nametest-9 :)
(: Description: Name test that attempts to select non-existent nodes from a newly constructed.:)
(: Use fn:count to avoid empty file.  :)

(: insert-start :)
declare variable $input-context1 as document-node() := document { <doc/> };
(: insert-end :)

let $var := <a attr1 = "abc1"><b attr2 = "abc2">context2</b></a>
return
  fn:count(($var/empty-node-list)[1])

I believe:

Constr-elem-empty-3
Constr-elem-empty-4
Constr-cont-adjtext-3
Constr-cont-adjtext-4

to be correct for similar reasons to those outlined above for nametest-9.

The errors found in:

K-FilterExpr-82
K-FilterExpr-83
K-FilterExpr-84
K-FilterExpr-85

stem from the differences between the descriptions of fn:boolean in F+O and FS.  This is discuessed in bug 4024.

If we implement the xs:boolean static typing rule in Formal Semantics we found about 120 further errors over those that we have already reported, including ST-WhereExpr001, ST-WhereExpr002 and statictyping-7.

An attempted fix has been committed to CVS, and should be part of XQTS_current.zip. Feel free to verify that the fix is acceptable, and if so, change status to CLOSED. If the attempted fix is not acceptable, reopen this report.

If no opinion about this resolution is expressed within two weeks, it will be closed.

Along with the fix for this report, was committed fixes for other reports as well. Also, a significant amount of new tests were added to cover missing areas and changes in the specifications.

Not fixed:

fn-intersect-node-args-003
K-WhereExpr-2

Fixed or no change required:

nametest-9
K-RangeExpr-31
K-RangeExpr-32
K-FilterExpr-82
K-FilterExpr-83
K-FilterExpr-84
K-FilterExpr-85
K-FilterExpr-82
K-NumericAdd-40
K-NumericAdd-51
K-NumericAdd-52
K-NumericAdd-53
K-NumericAdd-54
K-NumericAdd-55
K-NumericAdd-56
K-NumericAdd-57
K-NumericAdd-58
K-NumericAdd-61
K-NumericAdd-62
K-GenCompEq-34
K-GenCompEq-35
nodecomparisonerr-1
K-NodeSame-1
K-NodeSame-2
nodecomparisonerr-2
K-NodeBefore-1
K-NodeBefore-2
nodecomparisonerr-3
K-NodeAfter-1
K-NodeAfter-2
Constr-elem-empty-3
Constr-elem-empty-4
Constr-cont-adjtext-3
Constr-cont-adjtext-4
ForExprType002
ForExprType015
K-WhereExpr-1
K-QuantExprWith-18
K-SeqExprCast-144
K-SeqExprTreat-11
K-SeqExprTreat-12
K-SeqExprTreat-15
K-FunctionProlog-18
K-FunctionProlog-19
K-FunctionProlog-25
K-FunctionProlog-30
K-FunctionProlog-39
K-FunctionProlog-58
fn-name-16
K-SeqIndexOfFunc-12
K-SeqIndexOfFunc-14
K-SeqDistinctValuesFunc-7
K-SeqDistinctValuesFunc-8
K-SeqRemoveFunc-14
K-SeqRemoveFunc-15
K-SeqOneOrMoreFunc-3

Whether any of these require further attention depends on the clarifications of the points made in earlier comments.

A fix has been attempted in CVS, and XQTS_current.zip has been updated to contain the new change. If it can be verified that the change is correct, it would be appreciated.

If this resolution is satisfiable, feel free to change status to closed. Otherwise, reopen this report. If no opinion on the resolution is expressed within two weeks, I will change status to closed.

This change to this report was part of a batch-change of several reports.

K-WhereExpr-2 is now fixed.  Thanks.

This bug is still outstanding.

The argument to fn:root needs to be a zero-or-one sequence, but is statically typed as a zero-or-more sequence.

(:*******************************************************:)
(: Test: fn-intersect-node-args-003.xq                   :)
(: Written By: Ravindranath Chennoju                     :)
(: Date: Tue Jun 14 03:34:54 2005                        :)
(: Purpose: arg: node                                    :)
(:*******************************************************:)

(: insert-start :)
declare variable $input-context external;
(: insert-end :)

$input-context/bib/book[3]/title intersect root($input-context/bib/book[3]/title
)

Yes, closing this report was wrong. I forgot that there was a test other than those I have responsibility for. Reassigning to Ravindranath.

A fix has been attempted in CVS, XQTS_current.zip is updated.

If the resolution is satisfactory, feel free to change status to CLOSED. Otherwise, reopen this report. If no feedback is returned within two weeks, status will be changed to CLOSED. Thanks for reporting!

That fixes it for Anglo.  Thanks.