Probably not where to post tis, but a place
where several of the right people will get it anyway.
The duration data type is an incomplete
instantiation of duration as defined in ISO8601. In
particular, it omits weeks, which are very useful for many
human-centric communications. As the internet of things
begins to integrates devices and people, such communications
are likely to grow more important.
In ISO8601, the elements of duration
include second, minute, hour, day, week, month, year.
XML duration supports second, minute, hour,
day, month, year
RFC5545 (previously 2445) defines duration
using second, minute, hour, day, week.
Where ICalendar and XML overlap, they are
identical.
xCal (RFC 6321) is the recently completed
XML representation for iCalendar information. Because of the
mismatch above, it uses its own string restrictions to define
what it calls a duration. The overlapping is makes it worse.
If XML fully implemented iso8601, then today’s xCal would be a
strict sub-set; tomorrows could grow to identity, which would
improve many uses.
The larger durations are not just multiple
of the smaller durations. A day!= 24 hours, although it
usually does. A month is clearly a variable number of days,
and processing rules can define what a month from February 15
is as well as a month from May 15. A year is not always 365
days,
The week appears to be no more than a
multiple of 7 days, which is why, I assume, the XML committee
left it out. When it intersects with the world of people, and
of business, though, there are a multitude of differences. “Do
this at the start of each week”, at a duration of 1W, might
indicate a service performance on Tuesday in weeks in which
there is a holiday on Monday. Many calendar specifications,
such as recurrence rules and availability communications use
durations denominated in weeks.
What is the correct approach, and where is
the correct forum to start a conversation on fixing this?
tc
"You can
cut all the flowers but you cannot keep spring from coming."
-Pablo
Neruda.
