in http://dev.w3.org/2007/xquery-update-10-test-suite/TestSuiteDocumentation/Guidelines%20for%20Running%20the%20XML%20Query%20Update%20Test%20Suite.html,
we shall add (xs:untyped) in document-node() definition
Users of static typing may choose to transform the variable declarations between insert-start and insert-end comments by adding an "as document-node(xs:untyped)" clause as illustrated below:

Sounds good.  I verified that modifying our test framework to rewrite the variable declaration using "as document-node(element(*, xs:untyped))" fixes the problem.  Thanks.

Why was this closed?  It does not appear that the guidelines have been changed yet.  Why is this bug "invalid"?

Apologies. I read your issue and Zhen's response too quickly and thought that you were satisfied with our current guidelines.

I believe that you are asking us to extend the guidelines, allowing the adding of both "as document-node()" and "as document-node(element(*, xs:untyped))".

I'm not strong in our static typing, so I'll have to ask some of our other members to comment on this. I note that we've had similar requests in the past in Bug #3012, Bug #3972, Bug #4046, and Bug #7216.

No problem.  Yes, your understanding is correct.  Another option is to modify the 6 tests.  Thanks.

Allowing users to set
document-node(element(*), xs:untyped)

shall solve the problem without modifying the tests.
However,
We need to state so in
http://dev.w3.org/2007/xquery-update-10-test-suite/TestSuiteDocumentation/Guidelines%20for%20Running%20the%20XML%20Query%20Update%20Test%20Suite.html

(In reply to comment #6)
> Allowing users to set
> document-node(element(*), xs:untyped)
> shall solve the problem without modifying the tests.

Zhen, is this a necessary change? Is there a problem with these test cases if only "as document-node()" is added?

 

If only static type of 'docuement-node()' is used, then it means the input document could be either untyped or typed, so this means the conservative static
typing has to raise static type errors for comparison in the predicate
employee[@name='Jane Doe 1']
since @name might be xs:integer, so it is an error to compare with xs:string.
This is what Josh explained in the original bug comment.
However, if we set the static type to 'document-node(element(*, xs:untyped)), then
no static type error is raised for handling the predicate comparison. So  the real intention of the test to test static typing for updating expression is
realized.

(In reply to comment #5)
> Another option is to modify the 6 tests.

E.g., by changing "@name" to "(@name treat as xs:string)" ?

I would rewrite them as follows:

$input-context/works/employee[@name='Jane Doe 1']

becomes

$input-context/works/employee[1]

I don't think that would entirely work. The point of an expression like
    $input-context/works/employee[@name='Jane Doe 1']
is that its static type has cardinality greater than one, but its value has cardinality one. (So an implementation that supports the Static Typing Feature will raise a type error during static analysis, but an implementation that doesn't support the STF won't raise a type error at all.)

With an expression like
    $input-context/works/employee[1]
then, yes, when $input-context has the default static type item()*, the expression will still have the properties given above. But if an implementation chooses to replace the default declaration with:
    declare variable $input-context as document-node() external;
then I believe the Formal Semantics rules would cause it to infer a static type of cardinality zero-or-one for the expression, and therefore not raise a type error.

You are right, I forgot you need the *.  Would $input-context/works/employee work?

No, because then both the STF and non-STF implementations would raise a type error.

OK, then could we do a slight variation on your original suggestion?
"@name" to "@name treat as attribute(name, xs:string)"

or even 
"@name" to "data(@name) treat as xs:string"

Sorry, I am not trying to be difficult :)   

With your original suggestion, our implementation detects that even with the
treat expression, it is impossible for "attribute (name, anyAtomicType)" to
become "xs:string" at runtime so it still fails statically.  Note, the input to
the treat expression is not atomized. 

(: Name: stf-insert-into-01 :)
(: Description: insert-into: ST of TargetExpr has cardinality greater than one. :)
The purpose of this test is to show ST raises static type error by infering
the $target has static type with occurance of either 'zero or one', or 'zero or
more'.
So
$input-context/works/employee[1] shall raise static type 
error as the ST is zero or one of element(employee)
and
$input-context/works/employee[@name='Jane Doe 1'] shall raise static type
error as the ST is zero or more element(employee)

$input-context/works/employee[@name='Jane Doe 1'] shall raise static type
error as the ST is zero or more element(employee)


So as long as we set the static type
for $input-context to 'document-node(element(*, xs:untyped)), the expected
static type would be raised without the need of changing the tests.

Zhen - I agree that changing the guidelines or changing the tests will fix the problem.  Why do you think changing the guidelines is better?

No difference between changing the tests or the guideline of 
setting $input-context to 'document-node(element(*, xs:untyped)).

However, in general to really test
more on static typing (pessimistic based), it helps more to set
$input-context to 'document-node(element(*, xs:untyped))
instead of
setting $input-context to 'document-node(element(*)).

Currently, the XQUTS guidelines *allow* the test harness to add
    as document-node()
to the decl for $input-context. In order for the six tests in question to work unchanged, we'd have to *require* the test harness to add
    as document-node(element(*, xs:untyped))
So that's two changes.

Moreover, I believe there are test-cases in XQUTS for which requiring that addition could cause problems. E.g., for a query involving books.xml, if an implementation constructs a typed XDM instance for the document, then it can't bind that value to a variable that has been declared as document-node(element(*, xs:untyped)). So the guidelines would have to address that somehow.

If instead we change the six queries, then the guidelines (and thus test harnesses) don't need to change. (My guess is that it's easier for implementors to rerun the suite with changed queries than it is for them to change their test harnesses.)

A third approach would be to change the six queries, but rather than tweaking the @name in the query body, explicitly add "as document-node(element(*, xs:untyped))" to the declaration of $input-context.

Josh, how do you feel about my "third approach"? (Explicitly change the declared type of $input-context in those six queries, and leave the query bodies as is.)

So to recap, I think we have three viable options suggested:

(a) Modify the queries with something like "@name treat as attribute(name, xs:string)"

(b) Modify the test guidelines to require a rewrite of the variable declaration as "document-node(element(*, xs:untyped))"

(c) Modify the queries to rewrite the variable declaration as "document-node(element(*, xs:untyped))"

Based on what Michael points out in Comment #18, I would vote against (b).  I would be happy with (a) or (c).

At its meeting on 2010-05-18, the XQuery WG decided to adopt the solution given as option (c) in comment 20. I have made the necessary changes (in both XQuery and XQueryX versions of the queries) in XQUTS. Therefore, I am marking this bug resolved-FIXED.

Since you said you would be happy with this option (c), I am also taking the liberty of marking this bug CLOSED.