W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2004

Re: Proposed Text on Clocks

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 8 Nov 2004 17:39:16 +0100 (MET)
To: Martin Chapman <martin.chapman@oracle.com>
cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
Message-ID: <Pine.GSO.4.61.0411081728090.1921@gnenaghyn.vaevn.se>
On Thu, 4 Nov 2004, Martin Chapman wrote:

>
> I propose the following to be insterted into the introduction:
>
> 1.6 Time Assumptions
>
> CDL has been designed to support intra and inter business activity. In 
> such an environment, it is acceptable for different parties to be 
> synchronizsed on second boundaries and not by finer grained boundaries 
> such as milli, micro, or nano seconds. Thus there is an assumption that 
> each party is responsible for its own synchronization to UTC and that no 
> clock synchronisation protocol is required. Applying CDL to a different 
> environment where finer granularity and synchronisation is required, 
> e.g. real-time embedded systems, is possible, but will required 
> additional support not defined here.

How about something along the lines of:
<<
CDL does not put any assumption on clock synchronization between involved 
parties. In some specific environments, like usual business activities, it 
can be assumed that all parties are reasonably well synchronized on second 
boundaries, however for all application requiring finer grain time 
synchronization or that have same-time requirements amongst all 
participants, additionnal support and control may be required but is out 
of the scope of the CDL specification.
>>

It seems safer to say that in the general case, we can't consider clocks 
to be synchronized so that designers won't reach the case where a supplier 
is off by one hour without being warned that using relative time on 
participant is more reliable that assuming synchronized clocks (even on 
second boundaries).

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Monday, 8 November 2004 16:41:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:10 GMT