W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2008

[Bug 5717] [F&O] Definition of op:divide-dayTimeDuration-by-dayTimeDuration and op:divide-yearMonthDuration-by-yearMonthDuration

From: <bugzilla@wiggum.w3.org>
Date: Wed, 04 Jun 2008 16:50:09 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1K3wBd-0003Nm-Up@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5717





------- Comment #1 from mike@saxonica.com  2008-06-04 16:50 -------
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
Received on Wednesday, 4 June 2008 16:50:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:52 GMT