This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17462 - [QT3TS] K-SeqExprCast-3, 4, 7, 9-13, K-SeqExprCastable-4 to -6, 12, 13
Summary: [QT3TS] K-SeqExprCast-3, 4, 7, 9-13, K-SeqExprCastable-4 to -6, 12, 13
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: O'Neil Delpratt
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-11 15:33 UTC by Tim Mills
Modified: 2012-10-10 13:38 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2012-06-11 15:33:39 UTC
Tests such as 

'string' cast as xs:anySimpleType
'string' cast as xs:untyped
'string' cast as xs:anyType
3 cast as xs:doesNotExist
'string' castable as xs:anySimpleType
'string' castable as xs:untyped

which expect XPST0051 in XQ10 should expect in XQST0052 XQ30.

This is because of the change of SingleType (as used in cast and castable expressions) from AtomicType? to SimpleTypeName?.

err:XPST0051

    It is a static error if a QName that is used as an AtomicType in a SequenceType is not defined in the in-scope schema types as an atomic type.

err:XQST0052

    The type must be the name of a type defined in the in-scope schema types, and the {variety} of the type must be simple.
Comment 1 Tim Mills 2012-06-12 11:07:10 UTC
K2-DefaultNamespaceProlog-12 has a similar problem.
Comment 2 O'Neil Delpratt 2012-09-25 11:20:39 UTC
I suggest for these tests cases that we include in the result the following opions:

         <any-of>
             ...
            <error code="XQST0052"/>
            <error code="XPST0051"/>
         </any-of>

Do you agree?
Comment 3 Tim Mills 2012-09-25 11:25:55 UTC
As this shows a difference between XQ10 and XQ30 behaviour, I think the tests will have to be duplicated with appropriate dependencies on XQ10 or XQ30.
Comment 4 O'Neil Delpratt 2012-09-25 11:32:58 UTC
(In reply to comment #3)
> As this shows a difference between XQ10 and XQ30 behaviour, I think the tests
> will have to be duplicated with appropriate dependencies on XQ10 or XQ30.

Yes it makes sense. I will add the new tests for XQ30
Comment 5 O'Neil Delpratt 2012-09-25 13:57:33 UTC
Test cases added and committed to cvs
Comment 6 Tim Mills 2012-09-25 15:05:05 UTC
The 'old' tests need to be marked

   <dependency type="spec" value="XQ10"/>
Comment 7 O'Neil Delpratt 2012-09-25 15:24:38 UTC
Ok. Made the change as suggested. Committed to cvs.
Comment 8 Tim Mills 2012-09-27 09:57:34 UTC
Sorry, I missed one out.  K-SeqExprCast-5 has a similar problem.

Also, the annotations should also include XP20 (for those marked with XQ10) and XP30 (for those marked with XQ30).

Furthermore, I suspect that K-SeqExprCast-4a and K-SeqExprCastable-5a should expect XPST0080, but the definition of XPST0080 will have to extend to cover this.  I have raised this as a bug against the spec (Bug 19090).
Comment 9 Tim Mills 2012-09-27 10:02:21 UTC
Test K2-DefaultNamespaceProlog-12 also needs to be duplicated and fixed for XQ30+/XP30+ to expect XQST0052.
Comment 10 O'Neil Delpratt 2012-10-01 14:24:25 UTC
Test cases mentioned in comment #8 and comment #9 now fixed
Comment 11 Tim Mills 2012-10-10 10:09:45 UTC
Tests K-SeqExprCast-4a and K-SeqExprCastable-5a need to be updated to expect XPST0080 after the decision in yesterday's teleconference regarding Bug 19090.
Comment 12 O'Neil Delpratt 2012-10-10 10:23:34 UTC
(In reply to comment #11)
> Tests K-SeqExprCast-4a and K-SeqExprCastable-5a need to be updated to expect
> XPST0080 after the decision in yesterday's teleconference regarding Bug
> 19090.

Ok. Error code changed accordingly.
Comment 13 Tim Mills 2012-10-10 13:20:34 UTC
K-SeqExprCastable-5a still appears to be unchanged.
Comment 14 O'Neil Delpratt 2012-10-10 13:38:37 UTC
(In reply to comment #13)
> K-SeqExprCastable-5a still appears to be unchanged.

Oh, I made the mistake in changing K-SeqExprCast-5a instead. I have now fixed this and confirm the test case K-SeqExprCastable-5a has been updated accordingly