Hi Mario, yes, this is the only reliable way of modus operandi. Having said that, I propose to add an additional chapter 3.4 explaining the use and semantics of xs:dateTime in OGSA-DMI: " 3.4 Using dates and times in OGSA-DMI OGSA-DMI makes use of the XML Schema data type xs:dateTime in various places, for example to express the point in time when a DTI has finished, or to convey a certain point in time in the future where the DTI shall start transferring. However, the XML Schema data type xs:dateTime allows to give dates and times both with and without time zone. While dates and times including time zones express absolute dates and times on a timeline, dates and times without time zones express relative dates and times that must be interpreted according to some context. This context-dependant interpretation often leads to ambiguous situations. Hence OGSA-DMI service implementations, when emitting dates and times, MUST express all dates and times (for example, the DTI's StartTime attribute) using a time zone to relieve clients of knowledge of the service's location. Also, OGSA-DMI implementations, when receiving dates and times that do not include a time zone, MUST evaluate that date and time in the service's local time zone." What do you think? Cheers, Michel On 16 Oct 2008, at 12:23, Mario Antonioletti wrote:
Hi, I'm ok about the proposed change below - just one point of clarification - only query that I have is the canonical time for this is the server time in the timezone the server lives in - right? I have a vague recollection that we did discuss this ...
For the group: I think we need to slightly reword the Functional Specification better describing the StartNotBefore transfer requirement.
It currently reads as: "This represents the [startNotBefore] information element. The data transfer encapsulated by the DTI MUST NOT start before the date, time and time zone specified by this element. If not specified its default value will be the date and time that the DTI was created. The DTI MUST NOT enter the transferring state before this time unless the “Start” operation on the DTI is invoked."
I propose to replace that with the following paragraph: "This represents the [start not before] information element. The data transfer encapsulated by the DTI MUST NOT start before the date, time and time zone specified by this element. If not specified then the DTI MUST wait for a client to invoke the Start operation before it can enter the Scheduled state."
+1
Mario
+ -----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | + -----------------------------------------------------------------------+ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
-- Michel Drescher Fujitsu Laboratories of Europe, Ltd. Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE Reg. No. 4153469 +44 20 8606 4834 Michel.Drescher@uk.fujitsu.com