[
Lists Home |
Date Index |
Thread Index
]
On Sat, Oct 11, 2003 at 11:16:08AM +1000, Rick Marshall wrote:
[...]
> datatypes as we use them aren't very good. the zip code example earlier
> is a good example - looks like a number, but isn't and the concept of
> 2002 - 1075 when they are zip codes (or post codes etc) is meaningless
> and we have to be able to express that.
Agreed.
> adding dates is meaningless
No, if you add two dates you get an orgy :-)
> (but subtracting dates is meaningful), but adding days to a date is
> meaningful. and dates aren't numbers either.
There have been programming languages in which one defines
a type by giving a value space together with operators defined
by axioms and invariants that hold over those operations.
The first such language I saw was EqLog, in the early 80s; it
used logic (propositional calculus and Horn clauses I think,
it's been a while) to prove some essential properties about
the axioms so as to ensure type safety. (e.g. closure over
the value space, I expect).
It looks like "OBJ" [1] and "OBJ3" [ibid] may have come out of
that research.
I know there are people familiar with this sort of research on
the XML Query Working Group, and I suspect on the Schema WG as
well, who cold say a lot more about it than I could.
Rick mentioned dates and durations, so I'll say a bit more
about them to show how tricky they are... yes, if you
subtract 20th June, 1837 from 20th July 1837, yuo get either
"a month" or you get 30 days.
If you then add the resulting duration to 30th January, 2003,
you get either 30th February 2003 (probably an error) or you
get nd March 2003, which might or might not be what you wanted.
Possibly you wanted "the last thursday in the month, at 5pm in
the local timezone, after accounting for daylight savings time,
but if the resulting day is a holiday, skip that month".
Why is this difficult to express in an algebra?
Part of the answer is that it's complicated, rather than
simply exhibiting complex behaviour... but part. I claim, is
that our algebras over number systems all take the idea of
a constant "unit". With months, the unit is sometimes 30 days,
sometimes 31, sometimes 28 or 29, and once in the early 1750s
there was a month of only 16 or so days.
Even the length of a day is not in fact entirely constant,
because of leap seconds, and because of daylight savings time.
(I would like to make a withdrawal from my savings, please!)
So date arithmetic must be grounded in history and astronomy,
and in the case of daylight savings time, in politics and
national and regional boundaries, in geography.
The XML Query Data Model extends the W3C XML Schema concept
of date and time slightly, to store the local name of the
timezone; this is needed so you can implement appointment
reminders correctly, as in the "thursday" example above.
One approach to arithmetic is to convert durations to a
number of seconds, and dates to a nuber of seconds past some
epoch, an offset from UTC, and a local timezone name. This
does seem to simplify things, but there have been whole books
written on calendars and time calculations, of course.
Part of me agrees with James Clark in saying it'd be better
if W3C XML Schema had not defined date and duration types,
but had simply stuck with the ISO time format and not
prevented the 31st of February. But it is done now, and
in any case there was (and remains) strong demand for it.
If we have durations, though, which are physical extents in
the temporal dimension (as Dr Who might have said), there's
really no excuse for not including the other physical dimensions
of leftness, downness and backishness.
Any extensible type system that attempts to represent physical
constructs, as measured by we feeble-toed humans, ought,
in my view, to be able to represent voltage, resonance and
frequency of oscillation, mass, and other physical values,
along with correct unit derivation: multiplying a leftness
by a backishness gives an area, and multiplying a leftness
by a leftness is probably an error. Dividing an alongness
(e.g. a downness) by time gives a speed (m/sec). And so forth.
So maybe I am agreeing with Rick in part, although I think his
examples made durations and dates sound simpler than they can
be in practice and still be useful.
Best,
Liam
[1] http://www.cs.ucsd.edu/users/goguen/sys/obj.html
and pointers therefrom.
--
Liam Quin, W3C XML Activity Lead, liam at w3.org, http://www.w3.org/People/Quin/
Extracts from old books online (mostly in XML) -
http://www.holoweb.net/~liam/old-books/
|
