[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-calendar] Comments on WS-Calendar-1 0-spec-wd-06.pdf
|
Benoît:
This is great feedback. I think I agree with everything you itemized; though I have not gone through each item with a strong comparison to the doc just yet.
There was one item that you asked about that I think/hope I can clarify:
--- Line 368 and 369: This statement sounds weird to me. “From 4:00 ending at 5:00” and “One hour beginning at 4:00” are the 2 ways to expressed the strictly same anchored period of time. They are equivalent in the mathematical sense. So how/why the services may be quite different ? ---
In this above example, they may be equivalent but there are at least two situations where they are not equivalent:
1) If the times were changed to: “From 1:30 AM ending at 2:30 AM” and “One hour beginning at 1:30 AM” In the US, these two example scenarios are different two days of each year: Daylight Saving Time change-over and Standard Time change-over (where the DST changes at the previous local time of 2AM). The first example scenario should produce an event that is either 0 minutes long or 120 minutes long (depending on spring-forward or fall-back rules). The second example should produce an event that is 60 minutes long regardless of any DST issues. DTEND - DTSTART = 0 || 120 minutes DURATION = 60 minutes
2) Keeping the same times as in the example: “From 4:00 ending at 5:00” and “One hour beginning at 4:00” If something prevents a scheduled action from starting right at 4:00 (instead causing it to start at 4:10, for example; the ‘Realized’ time), then the first example scenario should produce an event that is 50 minutes long, ending at 5:00. The second example should produce an event that is 60 minutes long; ending at 5:10. DTEND - Realized(DTSTART) = 50 minutes DURATION = 60 minutes
Again: great review of the doc; thanks.
Cheers, - Jeremy
Jeremy J. ROBERTS Technical Director LonMark International LonMark Technical Office PO Box 268, Jamison PA 18929, US Tel:+1-215-918-1026 mailto:jeremy@lonmark.org skype:lonmarkjeremy ____________________________________________
From: Benoît Lepeuple
[mailto:b.lepeuple@arcinfo.com]
Dear colleagues,
Here are my comments.
First 2 general points: - Following our discussions on the good terms to describe what are duration, interval and period, I felt on the Joda-Time API. They do have a very interesting description of the almost exact concepts. See the “Key concepts” part at http://joda-time.sourceforge.net/ - The WS-Calendar specification refers to xCal and iCal in many places, and there is nothing to say about that. But sometimes, we refer to both, sometimes only xCal, sometimes only to iCal, and it can appear strange, or having a particular importance that it does not have (just a writing artifact in general). Just as an example, starting line 305, in the duration definition, it is said “Well-known element from iCalendar and xCal”, but the next phrase says “Duration is an optional parameter of xCal objects vevent and vtodo.” This may be interpreted as “The Duration is optional in xCal, but not in iCal”.
Line 305: Duration definition – The way it is written is not really a definition, because we did not succeed in finding a fourth term explaining what we meant. It only gives an example of a duration in iCal/xCal. Why not using the term “time span” to define what a period is (a period of time not anchored to a specific date and time). Time span has the advantages of being used as is in some date and time APIs or libraries of objects (.net in particular), and not bringing a cyclic definition with “period that is not anchored”.
Line 332 editorial – “users” à “uses”
Line 338 editorial – “assembles” à “assembled”
Line 342 Precision: The term “Tolerance” is given as an example of this line 332, and it is called DurationPrecision line 458 – Could be homogenized. The term Granularity is used mentioning “as defined above”, but successive editorial changes removed the granularity definition. Accuracy: It cannot be of type xs:Duration, but in turn could be defined as an enumerated value. How a device with an accuracy of 1 minute could interpret a piece of information coming from another device indicating an accuracy of 1 millisecond. If defined by an enumerated type, one can guess that the communication partner is more or less accurate, and act/interpret data accordingly. If defined by a duration, this is not possible. The low accuracy device does not know what a millisecond is, but it could know what a “1 ms class” time information is: Something too much precise in which it could ignore part of the figures to act “at best”. In the “Attach” definition: ws-calendar:associatedArtifact is used for the first time with a mention “defined above”.
Line 360 editorial – “provde” à “provide”
Line 368 and 369: This statement sounds weird to me. “From 4:00 ending at 5:00” and “One hour beginning at 4:00” are the 2 ways to expressed the strictly same anchored period of time. They are equivalent in the mathematical sense. So how/why the services may be quite different ?
Line 382: Interval definition “An interval specifies a single segment of time”. Any reason not to use the same wording than line 305. Maybe I miss something: Should “single” be interpreted as “cannot be split” or “cannot be moved to another anchor in the time chronology” ?
Line 432: Allowing opposite definitions of relationships (PRECEDES and FOLLOWS) brings a major interop danger. One could use the relationships with PRECEDES only and another one with FOLLOWS only to express the same sequence, bringing possible interpretation issues. In addition this may facilitate falling in a cyclic-redundancy trap. I think it would be safer (but not easy) to define a consistent and complete (I hope the term is the good one, as used in maths) set of possible relationships. For example, “FIRST” or “LAST” is necessary, probably not both. In addition, the interpretation algorithm could be detailed to avoid interop issues (along with a conformance statement saying “Apply the algo yes/no”). Aren’t these things defined in BPEL ?
Line 443 to 478: Same remark on the example including relationships.
Line 519: Granularity is used and not already defined.
Line 519 – PartitionIntervals in the table: “Array of Duration Intervals” does not sound good to me. As a Duration is not the same thing as an Interval, what is a Duration Interval ?
Line 522 Editorial: “A schedule set is …” à “A period set is …” – “being” à “begin” –
Kind regards
Benoît LEPEUPLE Product Manager ARC Informatique
2 avenue de la cristallerie - 92310 SEVRES - FRANCE Tel: +33 1 41 14 36 00 - Mobile: +33 6 87 80 20 43 Email : b.lepeuple@arcinfo.com
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]