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 29913 - [qt3ts] Adaptive serialization - non-primitive atomic types
Summary: [qt3ts] Adaptive serialization - non-primitive atomic types
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Tim Mills
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-05 13:35 UTC by Michael Kay
Modified: 2016-10-07 09:57 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2016-10-05 13:35:08 UTC
The specification for adaptive serialization says:

An atomic value of any other type is serialized using the syntax of a constructor function: xs:TYPE("VAL") where TYPE is the name of the primitive type, and VAL is the result of applying the fn:string() function. 

This makes the following tests incorrect:

Serialization-adaptive-37, -41, -42

In each of these cases the expected result uses a non-primitive type (xs:dateTimeStamp, xs:yearMonthDuration, xs:dayTimeDuration).

May be worth raising as a spec issue, but for the moment, the test seems clearly to expect something different from what the spec says.
Comment 1 Tim Mills 2016-10-05 16:01:42 UTC
Do you have a strong preference either way?
Comment 2 Michael Kay 2016-10-05 16:48:18 UTC
I'm undecided. On the one hand, if the type information is there, it seems silly to lose it. On the other hand, I think xs:int is probably best displayed in the same way as xs:integer, so we lose the extra info in that case. I think the current spec is workable and that's what we've implemented, so I'm content with the status quo.
Comment 3 Tim Mills 2016-10-07 09:16:12 UTC
This should be fixed as requested.  Please confirm.
Comment 4 Michael Kay 2016-10-07 09:57:45 UTC
Confirmed OK.