Bug 15999 - [QT3TS] hof-039
[QT3TS] hof-039
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite
Member-only Editors Drafts
PC Windows NT
: P2 normal
: ---
Assigned To: Jim Melton
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-16 12:47 UTC by Tim Mills
Modified: 2013-03-14 12:02 UTC (History)
3 users (show)

See Also:


Attachments
Discussion document (3.60 KB, text/html)
2013-02-26 14:41 UTC, Tim Mills
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2012-02-16 12:47:31 UTC
I disagree with the expected result for this test.

The part of this which I disagree with is the following instance of test.

declare function local:f($x as xs:long, $y as xs:NCName) as element(e)?
{ <e x="{$x}" y="{$y}"/> };

local:f#2 instance of function(xs:long, xs:NCName) as element(e, xs:anyType)*,

The expected result (for this part of the test) is true .  I believe it should be false.

The function declaration has return type element(e)?.  Refering to the Formal Semantics specification, this expends out to:

[element(e)?]sequencetype
==
(element e nillable of type xs:anyType)?

Expading out the return type from the function type being tested, we get:

[element(e,xs:anyType)*]sequencetype
==
(element e of type xs:anyType)*

Note the absense of nillable.

Changing the test to:

local:f#2 instance of function(xs:long, xs:NCName) as element(e, xs:anyType?)*

would cause the actual and expected results to agree.
Comment 1 O'Neil Delpratt 2012-05-18 10:18:21 UTC
John you are the expert on this one, please can you adjudicate
Comment 2 John Snelson 2012-05-18 10:33:10 UTC
SequenceType matching in the spec says:

http://www.w3.org/TR/xquery-30/#id-element-test

2. element( ElementName ) matches any element node whose name is ElementName, regardless of its type annotation or nilled property.

3. element( ElementName , TypeName ) matches an element node whose name is ElementName if derives-from( AT, TypeName ) is true, where AT is the type annotation of the element node, and the nilled property of the node is false.

This seems to agree with Tim's analysis.


The SequenceType-subtype judgement says:

http://www.w3.org/TR/xquery-30/#id-itemtype-subtype

12. Bi is either element(Bn) or element(Bn, xs:anyType), the expanded QName of An equals the expanded QName of Bn, and Ai is either element(An), or element(An, T) for any type T.

This seems to contradict SequenceType matching, and is therefore wrong.



I agree with Tim's test change, but also think that the XQuery 3.0 spec, section 2.5.6.2, list item 12 should be changed to:

Bi is either element(Bn) or element(Bn, xs:anyType?), the expanded QName of An equals the expanded QName of Bn, and Ai is either element(An), element(An, T), or element(An,T?) for any type T.
Comment 3 O'Neil Delpratt 2012-05-29 10:03:25 UTC
We require WG discussion on this bug issue
Comment 4 Jonathan Robie 2012-05-29 15:41:59 UTC
The Working Group has agreed to change point 12 of:

http://www.w3.org/TR/xquery-30/#id-itemtype-subtype

To:

12. Bi is either element(Bn) or element(Bn, xs:anyType?), the expanded QName 
of An equals the expanded QName of Bn, and Ai is either element(An), 
element(An, T), or element(An,T?) for any type T.

The test suite still needs to be updated.
Comment 5 Jonathan Robie 2012-06-15 22:33:34 UTC
The resolution in Comment #4 seems wrong.

Instead of this:

12.  Bi is either element(Bn) or element(Bn, xs:anyType?), the expanded QName of An equals the expanded QName of Bn, and Ai is either element(An), <lookhere>element(An, T), or element(An,T?)</lookhere> for any type T.

Shouldn't it be this?


12.  Bi is either element(Bn) or element(Bn, xs:anyType?), the expanded QName of An equals the expanded QName of Bn, and Ai is either element(An), <lookhere>element(An), or element(An,T?)</lookhere> for any type T.
Comment 6 O'Neil Delpratt 2012-10-01 13:55:36 UTC
Test case result updated to agree with the suggested change in comment #0.
Comment 7 Tim Mills 2012-10-02 13:40:51 UTC
I still don't agree with the expected result.

It's possible to determine that

declare function local:f($x as xs:long, $y as xs:NCName) as element(e)?
{ <e x="{$x}" y="{$y}"/> };

will always return an element(e).  Thus this is equivalent to 

declare function local:f($x as xs:long, $y as xs:NCName) as element(e)
{ <e x="{$x}" y="{$y}"/> };

and so the result can be

"true true true true true true true true true false"
Comment 8 Tim Mills 2013-02-26 14:41:40 UTC
Created attachment 1327 [details]
Discussion document
Comment 9 Tim Mills 2013-03-14 12:02:01 UTC
This was discussed in XML Query/XSL WG Joint Teleconference #531 Minutes 2013-02-26.  The test suite was updated accordingly.