All time is relative. Ask Einstein. If my frame of reference is different than yours (and it always is; see Einstein) then a duration can often make the most sense for something like a retry interval. If I tell you to retry on March 15, 2005 and your system's clock is mistakenly set to the epoch, then you'll be waiting an awfully long time to retry. Conversely, if I tell you to retry at 2 pm ET today and your clock is mistakenly set to tomorrow sometime, you'll either be retrying too soon or never at all. A retry is just a convenience that says,"wait some period and try again... I might be up by then". If I tell you to wait 30 minutes and it takes an hour to get there, where is the harm if you wait an additional 30 minutes? For all I know, you have been retrying repeatedly in the interim because you didn't get the retry fault and didn't know better to wait. Or, maybe you're using WS-RM with the exponential backoff enabled and you're possibly going to ignore the retry fault and stick with that. Wimpy: "I'll gladly pay you Tuesday for a hamburger today" We all know that Wimpy never paid. Cheers, Christopher Ferris STSM, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com blog: http://webpages.charter.net/chrisfer/blog.html phone: +1 508 377 9295 public-ws-addressing-request@w3.org wrote on 03/03/2005 12:07:50 PM: > > > xs:dateTime is an instant in time, not a period of time > > Ask me Tuesday. > > > xs:duration is a period of time, not an instant in time > > Ask me in three days (implied: from now). > > > This proposal would make us look stupid to the entire community > > I hardly think so. A duration only makes sense when you have a base > time to use it with. What's the base time here? Is it when the server > sent the message, or the receiver got it? And suppose it's not HTTP-HTTP > but HTTP-SMTP? > > /r$ > > -- > Rich Salz Chief Security Architect > DataPower Technology http://www.datapower.com > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html > >Received on Thursday, 3 March 2005 21:26:28 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT