> I am not stressed either way, but I would use xsd:duration or
> xsd:dateTime rather than string. May as well use the
> appropriate SOAP type for it.

Hadn't spotted xsd:dateTime when I was writing the schema (or it may
have been it wasn't in the version of the XML Schema or the SOAP toolkit
I was using at the time...) otherwise I would have done so.

> I understand your arguments, but I think the assumption of
> clocks being synchronized is too big in real life. I think of
> all those PC's out there, including ones at people's homes
> etc. Then there are all the problems of time zones etc (and
> the fact that software writers do get it wrong at times).

Yes, there's a long standing bug on my Nokia that wo'n't sort e-mails
properly (particularly annoying with e-mails from Australia which always
sort to the top ;-) )
 
> I think time-to-live would be better as a duration, but where
> the value is a hint. The server is allowed to keep the result
> set longer or shorter as it deems appropriate.

Mmmm, my view is that the server agrees to keep the result set for this
time. It may keep the result set longer but shouldn't delete it before
this time (apart from in exceptional circumstances e.g. a crash).


> So duration has inaccuracy, date/time has smaller inaccuracy
> but relies on clocks being synchronized.
>
> Oh, more SOAP toolkits support date/time than duration by the
> way. <:-(

I think I would argue for date/time as being less ambiguous (even if not
more accurate in the real world) and allowing some future proofing in
that we can layer ZiNG over transports with higher latency should the
need arise, without making changes to the base spec. So we have 1 vote
for xsd:dateTime and 1 vote for xsd:duration. What do the others think?
Matthew