- From: Bernhard Bodenstorfer <bodenstorfer@yahoo.co.uk>
- Date: Fri, 19 Dec 2003 15:23:17 +0000 (GMT)
- To: public-qt-comments@w3.org
- Cc: bbodi@web.de
The origin of most problems with durations is that they depend on a reference dateTime so that they can be unambiguously interpreted. 1: Don't process durations without a reference dateTime ------------------------------------------------------- Because if you do, then trouble starts. Let me pose a provocative question: Are there really worthwile use cases that require duration processing without a dateTime to relate to? Actually, I have an impression that when one tries to e.g. compare durations without a dateTime, one should rather look for the flaw in the design. On the other hand, as long as it is passed on together with a dateTime, the use of durations can be justified. They are human-readable and I believe that all desired operations with durations can be put on a solid ground if a reference dateTime appears in some place. For example, if you have a reference_dateTime, then it is easy to compare. You just compare dateTimes: reference_dateTime + duration_1 < reference_dateTime + duration_2 (I think it is not difficult to understand the idea, though I used a sloppy "<" and a non-existing operator "+".) Secret advice for those who would not refrain from a healthy hack at times: You can always come up with an artificial fake reference_dateTime (like 2001-01-01T00:00:00Z) if you really want to handle durations alone. Let me conclude this topic expressing my concern about a quite large API when many functions are only necessary to bypass various headaches with durations that have no dateTime as a basis. I would rather honestly admit that simply you should not even think of doing it without. And I would only offer functions with a dateTime. The "+" operator brings me to my second topic: 2: There should be a function to add dateTime + duration -------------------------------------------------------- To illustrate why I believe that such an operator or something similar to the EXSLT function date:add( dateTime, duration ) should be available, let me shortly present the following use case: In a financial time series database, there are series with different measurement frequencies: daily, weekly, monthly, quarterly, semi-Annual, annual. Corresponding to those are enumerated duration codes P1D, P7D, P1M, P3M, P6M, P1Y. For each time series, the starting dateTime and the duration code is needed in order to enumerate the dates corresponding to the values stored: Assuming a function date:add( date, duration ) exists, I just take the start dateTime and the duration code to iteratively (in the template recursion) compute the dateTimes I need. Of course things may get even simpler if we have a "saxpy"-type operation with three arguments to express "dateTime + n * duration". This would (using a divide in half recursion or even a foreach-loop rather than an element-wise recursion) alleviate problems with very long time series. Let me conclude this topic: I acknowledge that the addition dateTime + duration is possible also if the duration is cleanly split into two parts as it is currently foreseen. However, for simple applications like the one sketched, I feel that the machinery one has to involve is a bit complicated. With kind regards, Bernhard Bodenstorfer --- Reference: http://www.w3.org/TR/2003/WD-xpath-functions-20031112 PS: Search for the typo in the WD: "semnatics" --- END --- ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Received on Friday, 19 December 2003 10:30:29 UTC