(In reply to comment #0)
> There are several issues with the test cases that use
> transform/copy+modifications in order to check if type information is dropped
> properly:
> 
> - testing if an attribute is typed as untypedAtomic using instance of
> directly, e.g. $var1/BOOKLIST[1]/BOOKS[1]/ITEM[1]/DIMENSIONS[1]/@UNIT
> instance of xs:untypedAtomic. Probably the attribute should be wrapped
> in fn:data()?

Agreed. I've replaced these tests with instance of attribute(*, xs:untypedAtomic).


> - use of fn:id/idref on nodes that are not part of a document. XQuery
> F&O, 15.5.2,1 says: "If $node, or the context item if the second
> argument is omitted, is a node in a tree whose root is not a document
> node [err:FODC0001] is raised". 
> In the setToUntyped case $var1 comes from direct element
> constructors, so no document node is present in the tree
> In other cases (id-transform-expr-049), $node is copied from a document, so the
> resolution depends on bug #6367

Agreed. The copy clauses have been changed to:

copy $var1 := document { <test><content/></test> }

The path expressions starting with $var1 have been adjusted accordingly.


> - Why should empty(data($var1/BOOKLIST[1]/BOOKS[1]/ITEM[1]/LANGUAGE[1])
>  be true? LANGUAGE contains content in $input-context. It is nillable,
> but I don't see in the spec why it should be nilled or why this content
> should be removed for another reason - but maybe I miss something.

Agreed. The results for these expressions have been changed to false.

> In addition, id-transform-expr-049 has a missing location step
> 
> return ($var1/ITEM[1]/DIMENSIONS[1]/@UNIT
> 
> should be used instead of 
> return ($var1/DIMENSIONS[1]/@UNIT

Agreed.

Please close this bug report if you agree with this resolution.

(In reply to comment #1)
> (In reply to comment #0)

I agree with the solution, with the a single exception:

It seems that I either overlooked a similar problem, or the fix introduced it:

setToUntyped-01 to -07 contain the line 

$var1/test[1]/BOOKLIST[1]/BOOKS[1]/ITEM[1]/PUB-DATE[1] instance of element(*, xs:untypedAtomic),

this should be changed to 

$var1/test[1]/BOOKLIST[1]/BOOKS[1]/ITEM[1]/PUB-DATE[1] instance of element(*, xs:untyped),

as element are not of atomic type.

In addition, similar problems of this type are in id-transform-expr-045,-046,-047,-048 and -50 - I missed them in the last report:

- all of them use id/idref on a copy that is not a document, but the copy of a element node inside a document. I propose to copy the full document and adapt the paths accordingly.

- id-transform-expr-50 also uses the incorrect attribute type test

> > There are several issues with the test cases that use
> > transform/copy+modifications in order to check if type information is dropped
> > properly:

> > - testing if an attribute is typed as untypedAtomic using instance of
> > directly, e.g. $var1/BOOKLIST[1]/BOOKS[1]/ITEM[1]/DIMENSIONS[1]/@UNIT
> > instance of xs:untypedAtomic. Probably the attribute should be wrapped
> > in fn:data()?
> 
> Agreed. I've replaced these tests with instance of attribute(*,
> xs:untypedAtomic).
> 
> 
> > - use of fn:id/idref on nodes that are not part of a document. XQuery
> > F&O, 15.5.2,1 says: "If $node, or the context item if the second
> > argument is omitted, is a node in a tree whose root is not a document
> > node [err:FODC0001] is raised". 
> > In the setToUntyped case $var1 comes from direct element
> > constructors, so no document node is present in the tree
> > In other cases (id-transform-expr-049), $node is copied from a document, so the
> > resolution depends on bug #6367
> 
> Agreed. The copy clauses have been changed to:
> 
> copy $var1 := document { <test><content/></test> }
> 
> The path expressions starting with $var1 have been adjusted accordingly.
>
> Please close this bug report if you agree with this resolution.
> 

(In reply to comment #2)
> I agree with the solution, with the a single exception:
> 
> It seems that I either overlooked a similar problem, or the fix introduced it:
> 
> setToUntyped-01 to -07 contain the line 
> 
> $var1/test[1]/BOOKLIST[1]/BOOKS[1]/ITEM[1]/PUB-DATE[1] instance of element(*,
> xs:untypedAtomic),
> 
> this should be changed to 
> 
> $var1/test[1]/BOOKLIST[1]/BOOKS[1]/ITEM[1]/PUB-DATE[1] instance of element(*,
> xs:untyped),
> 
> as element are not of atomic type.

I've modified these test cases to test both the type of the element and the type of its typed value with:

       $var1/test[1]/BOOKLIST[1]/BOOKS[1]/ITEM[1]/PUB-DATE[1] instance of element(*, xs:untyped),
       data($var1/test[1]/BOOKLIST[1]/BOOKS[1]/ITEM[1]/PUB-DATE[1]) instance of xs:untypedAtomic,


> In addition, similar problems of this type are in
> id-transform-expr-045,-046,-047,-048 and -50 - I missed them in the last
> report:

Agreed. These test cases have been modified to copy the source document.