- 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 UTC