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 13141 - [F+O30] op:gYear-equal may be in conflict with XML Schema (Seven-property model)
Summary: [F+O30] op:gYear-equal may be in conflict with XML Schema (Seven-property model)
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Working drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://www.w3.org/TR/xpath-functions-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-05 13:30 UTC by Harald Stoiber
Modified: 2011-07-19 20:59 UTC (History)
2 users (show)

See Also:


Attachments

Description Harald Stoiber 2011-07-05 13:30:05 UTC
When comparing gYear values in the course of simple type validation, a schema 1.1 processor is required to fill in the missing parts of the seven-property model from the template given in section D.2.1 (The Seven-property Model) and implemented in the timeOnTimeline algorithm as the datatype spec describes it. In the case of gYear, December 31st will be used as month and day. On the other hand, the dateTime template given in the description of op:gYear-equal prescribes the first of January.

In case that this deviation from XML Schema is not by intension, I wanted to point it out.

Cheers and greetings from Vienna,
Harald
Comment 1 Michael Kay 2011-07-05 17:56:05 UTC
I don't believe that this discrepancy has any observable effects. I suspect that historically, XSD fills in the template with components from the date 1972-12-31T00:00:00 because that year was a leap year and that day contained leap seconds; this date could therefore be combined with any xs:time value to produce a legal xs:dateTime. Now that leap seconds are no longer supported in XSD, the rationale for this choice has disappeared.

The only reason for using this machinery in XPath functions and operators is so that we can define xs:gYear operations in terms of xs:date operations. For that purpose, I think any month and day (other than 29 Feb) would work equally well. The reason for choosing 1 January is that the spec says that gYear values are compared by comparing their starting instants, and it's therefore logical to use the first day of the year in the actual algorithm. The same approach would still work if we chose to support ordering of gYear values.
Comment 2 Michael Kay 2011-07-19 15:29:05 UTC
The Working Group examined the comment and the response in comment #1, and agreed that there was no bug in the sense of things not working; they decided to make no change to the specification.

I would be grateful if you (the originator) would close the bug to indicate your acceptance of this decision; otherwise, please feel free to indicate what change you think is needed to the spec and why.
Comment 3 Harald Stoiber 2011-07-19 20:59:54 UTC
Since I have to agree with Michael that the differences of the two specs do not result in a different order relation for gYear values, I revoke my initial concerns and, thus, close the bug. :-)