# RE: Schema, Part 2: Datatypes

From: Biron,Paul V <Paul.V.Biron@kp.org>
Date: Fri, 3 Nov 2000 13:48:39 -0800
Message-Id: <376E771642C1D2118DC300805FEAAF4386DFEE@pars-exch-1.ca.kp.org>
```> -----Original Message-----
> From:	Jeff Lowery [SMTP:jlowery@scenicsoft.com]
> Sent:	Friday, November 03, 2000 11:07 AM
> Subject:	Schema, Part 2: Datatypes
>
> 1) I noticed a couple of definitions using the term 'positive negative
> infinity', which sounds like an oxymoron to me. Should it be 'positive and
> negative infinity'?
>
Yes, thanx for catching that...it is now fixed in an internal WG draft.

> 2) Priority feedback on timeDuration:
>
> Maybe I've been in the software industry too long, but I have trouble
> imagining any single task or set of tasks scheduled over more than a month
> having anything more than an approximate duration. So whether 1M = 30 days
> or 31 days or even 28 days may not matter for single tasks (composite or
> otherwise). Where it gets significant, however, is when you have sum of
> such
> tasks, or where you have a statistical mode of such tasks; then having an
> ordering for those durations could become critical for certain scheduling
> applications.
>

<inovice>
<p>
This invoice is due and payable in
<due-date xsi:type='xsd:timeDuration'/>3M</due-date>
</p>
</invoice>

[true: most accounts payable are expressed in terms of DAYS, in order to get
around the inherent indeterminism of time durations]

> The only way I see to solve the ordering problems is to allow
> specification
> of the month through a qualifier:
>
> 	1M(11)1D < 32D whereas 1M(12)1D = 32D; therefore 1M(11)1D <
> 1M(12)1D, where M(11) = November; M(12) = December
>
> If the month is unqualified, then 30 days is assumed, so that:
>
> 	1M1D < 32D
>
> The tricky part is February, which is codependent on leap year; that means
> we need a year qualifier as well:
>
> 	1Y(L)1M(2) > 1Y1M(2)
>
> Here, if the Year is unqualified, it is assumed to be 365 days and
> therefore
> also M(2) = 28.
>
> A bit messy, and I don't know if it conflict with the ISO 8601 spec, but I
> can't see a better way around the problem.
>
Yes, a bit messy and not compliant with 8601 but certainly worth considering
in a future version of the spec.

pvb
```
Received on Friday, 3 November 2000 17:01:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:53 UTC