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'?

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.

I use to work on documentation for airline maintenance tasks. One part of
the system involved 'load balancing' of maintenance tasks, so that some
maintenance was moved ahead of schedule to even out the distribution of
maintenance, which avoided fluctuation of daily crew man-hours. Of course,
some task, or composite task, scheduled to take a certain duration may slip
(or even finish early), but on average you could do a fairly reliable load
balancing. This is where a meaningful ordering of time duration could be
important.

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.

Received on Friday, 3 November 2000 14:07:55 UTC