For the time being this is a personal response - but it's also my formal response to an action by the WG to prepare a response for them to consider.

Firstly, I think that sections 10.3.1 and 10.3.2 do explain, perhaps not very elegantly, how the values of a yearMonthDuration and a dayTimeDuration can be considered to be an xs:integer and an xs:decimal respectively. Indeed, for yearMonthDuration it goes so far as to say that the value IS an xs:integer, and this justifies the phrase in 10.6.5 "the values of both operands are integers". For dayTimeDuration it says "The value space of xs:dayTimeDuration is the set of fractional second values." and I think the author was clearly considering that it was therefore a set of xs:decimal values.

Also, section 10.1.1 says: "The value spaces of the two totally ordered subtypes of xs:duration described in 10.3 Two Totally Ordered Subtypes of Duration are xs:integer months for xs:yearMonthDuration and xs:decimal seconds for xs:dayTimeDuration. "

I think this could perhaps be expressed better, but I don't think it's sufficiently wrong to justify an erratum.

>>There is no reason that the implementation defined limits on xs:dayTimeDuration fall within the implementation defined limits of xs:decimal; similarly for xs:yearMonthDuration.

Correct, I don't think the spec suggests that this is the case.

>Although it is obvious how a dayTimeDuration can be viewed as a decimal this is
never explained anywhere in the document, and the phrase "since the values of
both operands are decimals" is wrong.

I think it's explained in the sections cited above.

>Does this also imply that the errors raised are those raised by
op:numeric-divide (ie FOAR0002 for overflow, instead of FODT0002)?

No, I think the error on overflow is as stated in section 10.1.1.

There's a significant editorial problem with the F+O spec in that readers turn to the specifications of individual functions, and fail to find the mass of information in the general introductory sections. I would like to make the function specifications more self-contained by including references to the general sections that are relevant. But that's not something to be tackled by erratum.

>>It does seem rather odd that dividing a dayTimeDuration by xs:double(0) return
an FODT0002, but dividing a dayTimeDuration by xs:dayTimeDuration("P0S")
returns an FOAR0001.

I agree, treating divide by zero as equivalent to overflow seems a curious design choice. But it's not a bug.

So my proposal is, that despite the fact that you have uncovered some inelegancies in both the design and the exposition, that we decline to make any change to the 1.0 specification.

Michael Kay

The WG discussed this on 10 June 2008. We'll leave it open for the time being to give Oliver a chance to respond, but the current sentiment is to concur with comment #1.

In view of the lack of any pushback, the WG decided to close this with no action.