I think that the approximations are the only way to effectively handle the comparison. What I was suggesting, is don't employ the approximations till the last moment necessary. That is have the datatypes internal structure keep a separate integer of months and float of seconds and only in the compare() method actually employ the approximation.
Though we don't want to anticipate too much a type aware DOM, we do not to consider providing usable (by app writers) datatype classes so that an application writer doesn't have to duplicate the parsing code. We would also need these datatype classes to hold the values for the bounds so that we don't reparse constants over and over and over again. In this case, the requirements for a usable datatype class (that is, a distinct count of months) is a little higher than just the requirements for range checking (an approximate number of seconds). I don't think that we have any option except to disregard the start time since the schema datatype doesn't support the interval form that you mentioned (2000-01-19T13:00:00/P1M) and otherwise we would have to guess whether a neighboring attribute or element content is start or and end time and that is too risky. Don't get me started with recurringInstant. I think it is an abomination. -----Original Message----- From: George T. Joseph [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2000 2:33 PM To: [EMAIL PROTECTED] Subject: RE: Proposal for Xerces-J Schema validators for timeInstant and timeDuration I agree that 30D isn't always equal to 1M, I just don't know what to do about it. I don't think there's going to be a way to make everyone happy with timeDuration. If you specify a duration of 1M, do you mean 30D, or "this date next month", or "4 weeks from today"? If you specify 30D, is that less than 1M if you happen to be in January but greater than 1M if you're in February? Should a start instant even be assumed at all? What if you specify a duration of "2000-01-19T13:00:00/P1M"? Is that equal to "2000-02-01T13:00:00/P1M"? Should the start instants be disregarded during comparson? Should you be using recurringInstant instead of timeDuration? george -----Original Message----- From: Arnold, Curt [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2000 11:13 AM To: '[EMAIL PROTECTED]' Subject: RE: Proposal for Xerces-J Schema validators for timeInstant and timeDuration I had overlooked those sections. It definitely makes comparision precise. I don't think it is acceptible for an application to not be able to distinguish 30D from 1M since legally they are different things. Hopefully, you could parse out the months and years separately from the precise durations and the do your range checks like (this.months*259200+this.seconds) > (other.months*259200+other.seconds)
