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."
|